[Coco] gcc-coco revisited

John E. Malmberg wb8tyw at qsl.net
Sat Nov 1 10:50:01 EST 2003


KnudsenMJ at aol.com wrote:
> In a message dated 10/31/03 12:24:31 PM Eastern Standard Time, 
> dbree at duo-county.com writes:
>  
> BTW, years ago BYTE or some other mag listed some standard speed test 
> programs in C.  I copied one to OS-9 C on the Coco3, in three versions:
> 
> (1) All variables were local/automatic on the stack frame.  Ran pretty slow, 
> as expected.
> 
> (2) All vars were declared global (outside of main() ), but not Direct.  Ran 
> slow, maybe even slower than (1), due to the clunky U-relative PIC addressing.

This really is CPU/Compiler dependent.  And I saw someone mis-apply the 
results of such a test to basically cause a major problem on a project 
with almost undetectable data corruption.

If you know what assembly that a compiler will generate, you can predict 
what type of speed you will get.

In general:

Register will be fastest on most platforms.  (No fetch/store)

Register pointing to a specific memory location. (data fetch/store)

Register + offset pointing to a specific memory location. (offset fetch, 
data fetch/store).  This varies with architecture because the size of 
the offset will vary.  IIRC: The 6809 can have a small offset in the 
generated opcode.

A direct page reference is the same as a Register + offset access.  So 
in theory should be no different in access times than an 8 bit or less 
offset to a register.

> (3) Like (2) but I added Direct to all globals.  Tore up the town!  Maybe 4X 
> faster.

Based on the above, it sounds like the compiler was not tracking and 
optimizing the access to the stack variables.  It should be possible to 
fix that with GCC.

> BTW, there is a major issue with Direct vars.  The Linker needs to issue 
> stern warnings if the total number of Direct global vars exceeds the 256 bytes in 
> DP.  When code assembled to use Direct addressing goes after a variable that 
> didn't make it onto Direct Page, it's fireworks time!

The Linker would have to track individual Direct global sections.  The 
direct pointer can be moved as needed to bank switch between active sets.

So it would be quite possible to have more than 256 bytes of direct 
global varibles, just not all visible at the same time.

-John
wb8tyw at qsl.network
Personal Opinion Only




More information about the Coco mailing list