Path: utzoo!attcan!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: MWC & large arrays -- help!
Message-ID: <521@philmds.UUCP>
Date: 22 Jun 88 23:46:06 GMT
References: <734@cacilj.UUCP> <46700008@hcx2> <427@sp7040.UUCP>
Reply-To: leo@philmds.UUCP (L.J.M. de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 67

In article <427@sp7040.UUCP> jsp@sp7040.UUCP (John Peters) writes:
>
>	I have ran into this problem before to.  My brother regularly 
>corresponds with someone that helped with the 3.0 MCW developement.  so 
>here is the reason.  The MWC compiler uses signed short offsets from a 
>stack value for local variables.  this means that you have 15 bits or
>32K to use as an offset, question answered.  This is not true of global
>variables.  All global variables are long offset from a base address so
>the problem does not exist and structures and arrays can be as big as
>wanted.

Long offsets from a base address? What 68000 instruction do you have in
mind?? Probably you mean absolute addresses (with relocation that is).

Lets see how we can address memory on the MC68000:

1) (An) contents of the location pointed at by An (n = 0-7)
2) -(An) same as 1) but with predecrement of An
3) (An)+ same as 1) but with postincrement of An
4) w(An) word displacement from An; w is a 16 bit signed offset.
5) b(An,Rx) byte displacement with index; b being a 8 bit signed offset.
6) There are also the PC-relative adressing modes; basically like 4) and 5)
7) Absolute short (16 bit signed)
8) Absolute long (32 bit; of course limited by a 24 bit databus).

Your local variables are typically adressed by a(A6), with a being a
negative value for local variables, and a positive one for parameters.
    Static and global data? 1), 2) and 3) kommt nicht in frage, as it
would require loading the address register for each different variable.
4) is widely used by various compilers, but means that only 64K can be
addressed (GEMDOS initializes some address registers to point to the
start of the initialized and uninitialized data spaces; these addresses
can be found on the processes' basepage). 5) seems hardly likely, have
to waste two registers.
    Leaves us with 7): only for programs in low memory (or I/O
references); not useful for most cases (unless you can enforce this on
your program).  And 8): Absolute long. Note that the address generated
will be a long address relative to the start of the text segment; this
becomes relocated when the program gets loaded (GEMDOS does that for
you). This is the default that Lattice C uses (but you can have type 4)
addressing by a compiler option).

Speaking of addressing modes, I would prefer type 4) if the data fits
into 64K; the instruction is shorter and also faster than absolute
addressing. If the data is over 64K you'll probably have to use absolute
addressing (or else you could use something like LEA (An,Dx),Am and then
use Am; but this requires an additional overhead). There's also another
case in which absolute addressing is almost mandatory: when you make an
interrupt routine. When the program that sets up the interrupt vector
exits (memory resident), the data base register will be destroyed. In
this case I prefer absolute addresses.

>	Hope this helped.  I was taught to not use global variables much but 
>it seems that they have their place.

    You can often use static variables instead of global ones; they
have a more restricted scope and will be put in the same program
segment(s).  As for not using global variables, this is a tendency that
has come forth from the structured programming gurus; I think that you
may use it as a general rule. However, there are very often
values/variables in your program that have a program-wide or
module-wide scope; it would be both foolish and inefficient to not use
that fact.

>						--  Johnnie  --

      Leo.