[Coco] Basic09 Level 3

[Wayne Campbell]

That would be awesome too! On the subject, there is a difference between
what defines a short, an int and a long between 6x09 and 680x0 processors,
for those who may not know.

6x09: short: 2 bytes; int: 2 bytes; long: 4 bytes
680x0: short: 2 bytes; int: 4 bytes; long: 8 bytes

Wayne
On Aug 13, 2013 5:48 PM, "L. Curtis Boyle" <curtisboyle at sasktel.net> wrote:

> A 4 byte LONG variable type would be nice, too. Wouldn't need to put
> results from file size system calls, etc. into a REAL number. :)
>
> L. Curtis Boyle
> curtisboyle at sasktel.net
>
>
>
> On Aug 13, 2013, at 3:09 PM, Wayne Campbell wrote:
>
> > I have thought about modifications to Basic09 much through the years.
> DCom,
> > while it began as a meager attempt to unravel I-Code and give me my
> source
> > code back, became the container for all I wanted to do to make Basic09
> > better and more powerful. Since coming back to it in 2009, DCom has been
> > replaced by unpack, which still isn't completed and is currently in the
> > form of decode. As I pondered the features I wanted to see in Basic09, it
> > became clear that what really needs to be done is to rewrite Basic09 to
> > accommodate new features and more powerful functions. Below is what I
> have
> > thought of.
> >
> > 1. Replace the internal editor with a editing module that runs in a
> > separate window. While I am not able to give all the details of how to do
> > it, I believe that a combination of pipes and the use of a data module
> > makes it possible for the error checking in Basic09 to communicate with
> > (and pass data between) itself and the editor.
> >
> > 2. Using the internal debug mode as a guide, create a separate debug
> module
> > that also runs in its own window and communicates with Basic09 through
> > pipes and the data module, but also allows for debugging packed I-Code in
> > addition to unpacked I-Code.
> >
> > 3. TYPEs in Basic09 seem to run into problems once you reach three levels
> > of depth. What this means is:
> >
> > Record.field.field.field
> >
> > may not work as expected. I know that when passing a field of that depth
> as
> > a parameter to a called procedure, the value of the field does not get
> > resolved. Instead you get the value of the pointer to that field. As the
> > manuals for Basic09 do not hint at or specify a maximum depth, and indeed
> > seem to suggest that you can go as many levels deep as memory will
> allow, I
> > consider this to be a bug, but others may disagree.
> >
> > 4. Add a HEX$() function. There would need to be two versions,
> BYTE/INTEGER
> > and REAL.
> >
> > 5. Basic09 creates three tables for each procedure. They are the variable
> > reference table, the branch reference table, and the comments table. When
> > you pack the procedure(s), all of these tables are destroyed. I would
> like
> > to see an option that allows these tables to be saved to disk before
> being
> > destroyed. This would make decoding packed I-Code much easier, and would
> > allow for the restoration of original variable names and line numbers. At
> > the same time, I would like to see named labels and named constants added
> > to Basic09.
> >
> > I am sure I have forgotten something. When it comes to me, I will post it
> > as a reply to this post.
> >
> > Wayne
> >
> > --
> > The Structure of I-Code
> > http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code
> >
> > decode
> > http://cococoding.com/wayne/
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>