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.