[Coco] GCC: DFLOAT / DIRECT_PAGE

[KnudsenMJ at aol.com]

In a message dated 11/14/03 8:38:48 PM Eastern Standard Time, 
dbree at duo-county.com writes:

> If we do provide our own assembler/linker, one thing would be needed.  I
>  believe it was Mike Knudsen who mentioned that the MW linker did not
>  warn you if you had more than 256 DP bytes.  The linker should
>  check and warn you if more than this max was reached.  It shouldn't be a
>  problem to implement, and would be a very good addition.

Yes, it was me who said that, and I wish someone would prove me wrong and 
show that the MWC linker really does warn you.  Maybe it does -- ISTR that I 
never did exceed the 256 byte limit, even in UME.  So someone should write a 
simple test program (just declare "direct long" var01 thru var66 should do it).
 
>  >    A direct page reference, depending on the internals of the CPU may 
take
>  >    one less clock cycle than an 8 bit stack or register offset.  I would 
> need
>  >    to look at the 6809 specs to see if this is the case.  The difference
>  >    is that a register offset has to do an 8 bit fetch and 16 bit add, and
>  >    a direct page reference just has to do an 8 bit fetch.

ISTR that the speed difference is more than one clock cycle -- maybe two or 
three -- due to the irrational waste of cycles within the 6809 whenever the 
internal data bus is used.  Direct vars are well wroth the effort.

>  > 3. The direct_page attribute for a variable name will be able to take
>  >    a value indicating the program section that the variable will be in.
>  >    The attributes of the program section will determine the real address
>  >    of the program section. 

Umm, don't variables go in a PSECT, not a VSECT?
 
>  I'm not sure I understand what you're saying here. 

Ditto, see above. ;-)

>  I've been thinking in terms of all variables from
>  all modules to be stored consecutively in one area.  This would be the
>  case for OS9, but for RS-BASIC programs, this would not be necessary.
>  The only reason for this would be to utilize the DP function.

OS-9 C put all the vars together for two reasons -- to allow multiple 
processes to share the same code section, with different data sections (this requires 
rigid segregation of writeable data from code), and also to make it easier to 
pre-inititalize data with a single block write (as done by cstart.r).

>  Otherwise, it would not hurt for the variables to simply be stored at
>  the end of the code for the module.  I don't know about FLEX and other
>  systems.

Yes, this is traditional mono-processing coding style, but a third reason 
strikes me -- if multiple object modules are to be linked, having all the vars 
for each module in a known place makes it easier for the linker.  OK, putting 
them all at the end might be fine.  Actually, "classical" coding style was to 
slip in the latest var or two right after the next unconditional branch, so you 
had data mixed in with code all over the place.

>  Actually, it just occurred to me that it might be difficult to use
>  DP-referencing in BASIC.  For it to work, wouldn't we have to insure
>  that the variables began on an even page boundary?  Or at least, by some
>  means, determine an even page reference point for the variables.

I'm trying to remember how I did this.  I know I wrote one major piece of ML 
code that was called repeatedly (and returned to) a BASIC program.  It did 
music composition and direct synthesis (what else? ;-)  I know I used plenty of 
DP vars in the ML code, but somehow managed not to trample on BASIC's own vars.

I *think* BASIC actually leaves open quite a bit of DP for our use, while 
using a fair amount itself.  Obviously any compiler will have to know where these 
areas are.

But there's always the ML's ability to re-direct DP to wherever it wants, and 
put it back to 00 before returning to BASIC.  The ML can force full absolute 
addressing ">0003" to access "genuine" Zero Page stuff of BASIC's.

--Mike K.