[Coco] Basic09 Level 3

[Retro Canada]

this is only a convention from C compilers. For java int is always 32-bit.

On 2013-08-13, at 10:10 PM, Wayne Campbell <asa.rand at gmail.com> wrote:

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

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco