emjej@uokvax.UUCP (03/08/86)
[I'm posting this here because it's specifically 6809-related.] [I hope that you will look at mod.os.os9 for generic OS-9 material.] For people using the Microware OS-9/6809 C compiler, let me strongly suggest you consider judicious use of the "direct" storage class. Huh? you ask. Well, I'm glad you asked that. People familiar with the 6809 will know what I'm talking about, but a short explanation-- minis and micros sometimes provide short addressing modes to refer to a particular page, called the "direct page," which lets one get to important data quickly. Old-fashioned processors, e.g. the 4004 and its many bastard offspring, and the PDP-8, made the direct page live on page 0, so that, for a processor with a 64K address space, you'd typically give the low-order byte of the address of a direct-page datum, and the processor would effectively stuff 0 in the high-order byte. The 6809 is different. It has a direct-page register that is used for the high-order byte of direct page references, so that the direct page may be any 256 bytes (aligned so that it starts at XX00 for some hex value of XX). OS-9 gives each process its own direct page (and the kernel has one, too); setting/saving the DP register is, of course, just part of context switching. The process's direct page is the bottom page of its data memory. The C compiler puts global variables at the bottom of data memory, working up--so some indeterminate number of variables will show up on the direct page in any case. The problem is that they might not be the ones that you, as the programmer, know or determine to be the most important or most-used ones. Microware's C compiler, therefore, allows one to specify that global variables are "direct," i.e. to be given precedence for placement on the direct page. One can say, for example, direct char state; or direct extern char state; Asking for too much stuff in the direct page works just like excess register declarations, i.e. excess is ignored. It *does* make a difference--I tried some judiciously-placed direct declarations in a rewrite of the old CUG Unix ed-like editor, and it shrank the code by about 500 bytes. (I think the compiled code came to 15.5 Kbytes at the time.) Things got faster, too. For portability, I'd recommend typing DIRECT and then conditionally compiling with -dDIRECT=direct or -dDIRECT= as need be. In a header file, I use #ifndef DIRECT #ifdef OSK /* 68000s don't have direct pages * #define DIRECT direct #else #define DIRECT #endif #endif James Jones
knudsen@ihwpt.UUCP (mike knudsen) (03/11/86)
> [I hope that you will look at mod.os.os9 for generic OS-9 material.] > Mod.os.os9 seems to have died out -- after weeks of no action, came a request from the moderator for someone else to take the job, and not a peep since. > For people using the Microware OS-9/6809 C compiler, let me strongly > suggest you consider judicious use of the "direct" storage class. > > [explanation of it here] > It *does* make a difference--I tried some judiciously-placed direct > declarations in a rewrite of the old CUG Unix ed-like editor, and > it shrank the code by about 500 bytes. (I think the compiled code > came to 15.5 Kbytes at the time.) Things got faster, too. > > James Jones Right on about "direct." In fact, I found that direct variables are even faster than "register" (you get one, the U reg) since the compiler is too dumb to use the register effectively, but makes good use of direct page. Discovered using the notorious prime sieve benchmark. Even if the compiler did lots of optimizing, I suspect that only pointers (of any type) would gain from "register." But we C hackers use lots of those, right? Note that putting arrays[] in direct does nobody any good and just wastes it, since unlike the 6502 the 6809 has no direct-page indexed mode. mike k