The direct page register is not currently used by gcc on the CoCo, and it should be used.
John Malmberg was mentioning this with respect to floating point usage, and how we could use the direct page like the 68HC11 port does the zero page, as extra registers.
However, the question is, which page to use. Luckily, I have a somewhat straightforward answer:
The assembler in the tools we have includes a statement that will assure a set of data gets assembled on a direct-page boundary. We could, in the crt0 assembly code, include such a segment. The problem is, I'm not sure what happens when it gets around to linking.
Assuming we solve that (or it's not an issue), the crt0 would load the high byte of the address of that segment into the DP register. As long as the DP register isn't overwritten by called routines, everything should be fine, and we can just reference the soft-registers by their symbol names in the compiler, as the 68HC11 port does.
The DP clobbering is an issue, though, and so is figuring out if the direct-page segment gets linked in the right spot. Does anyone have any answers on this?
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that using the DP register is definitely a possibility but I don't think that it should be turned on by default, especially when compiling with RSDOS.
If you intend on suporting or eventually supporting the the creation of ROF files there is already support in the file format for DP variables for both both initialized and uninitialize data. I wouldn't think that the assembler would be much of an issue since management of the DP is pretty straight forward but it might require a little tweaking. Since OS-9 loads the the module/program at the top of the userspace and places the data starting at $00 that might be a good default setting.
Now RS-DOS is a different story but the approach is about the same. My suggestion for this is to use the $FExx range for the DP register and under the RS-DOS crt0/runtime use as few bytes as necessary for standard crt0 data in that page. This will leave an extremely popular page of RAM available for anything time critical such as FIRQ music routines. You can also have multiple DP targets for RS-DOS with one being the DP set to #$FExx, one for $0000, and one that used extended addressing only.
In both cases if you choose to provide options within the compiler to automatically generate DP access I would reserve it for crt0 and for several byte and word values. Using it for dereferenced data or data greater than 2 bytes probably isn't necessary as access to those vars will most likely be off an indexed register rather than directly accessed.
Just a few thoughts...
...Chet...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My idea was the reserve a part of crt0 (or crtn) as the extra "registers," about 32 bytes worth in total. This would be inside the executable image, which in RS-DOS would have to reside within &0C00-&7FFF, due to ROM issues. The libc I'd like to see come to light would use ROM routines for nearly everything.
My comment about the assembler was because I want to make sure that the section containing the 32 bytes starts at a 256 byte boundary, so that we can be sure it's all in the same page. I'd really rather leave &FExx alone.
Now, the purpose of this space is to emulate extra hardware registers. On the 6809, there's too small a number to be able to do floating point calculations, since up to three 32-bit registers would be needed at a time by the compiler. With the extra "registers", there's more space, and gcc will merge registers if there aren't any that can hold a value of a certain size alone.
It's not incredibly efficient to even be using DP variables for this purpose, and any other type of addressing would be even slower. These "registers" could be used at any time, and might be used frequently.
I'm likely to implement this for all targets, unconditionally. That way floating point support is available for everyone, all the time, and it might even be possible to integrate our changes into mainline gcc.
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed the lack of DP indexing mode when playing around with gcc-m6809. If I'm not mistaken, I believe gcc simply allocates extra autovariables in the stack for the purpose of supplying extra "registers". Gcc seems to always use system stack pointer ( or maybe user stack, I don't remember) along with the 6809's indexed addressing mode to get at these "hidden" autovariables. I'm pretty sure there is different flavors of index addressing, including a 5, 8, and 16 bit offset opcodes. I'm assuming the as6809 assembler/linker chooses the best fit. These ops ( specially the 5 bit offset up ) aren't much slower then the Direct Page addressing mode. Is there really a need to include DP in gcc-m6809? I will re-look at the opcode and cycles for these commands as I know gcc-m6809 uses the stack/indexed autovariables A LOT. So maybe the DP would possibly save a lot of cycles over the length of a large program?
Also, I guess we must think of the ram savings too. most DP addressed ops require 2 bytes. where as the register-index addressed ops require more ram ( as follows ):
note that the 5 bit's offset is encoded in the low bits of the 1st arg.
As a side note, if you're planning on compiling for RSDOS, I'm pretty sure any "system" calls ( including the 60hz timer interrupt of RSDOS ) requires the the DP be loaded with page 0x00 in order to work. I'm assuming there's way to get around this. Any sort of RSDOS libc would have to store/reset the DP prior to and after a system call. crt0 might have to replace the timer vector to code that replaces 0x00 in the DP, and then jump to the regular handler.
Another side note: I don't know much about OS9, but I'm pretty sure it requires special compiling/assem/linking, being that OS9 (as I know it) require all progs to be written in position independant code (PIC, using lot's of leax's). I don't think gcc/as09/ld09 does this yet. That's one of the reasons my own homemade linker doesn't do the final "absolute address" pass. It lets my bios add the proper base addresses to the linked executable, thereby allowing the bios/os to put the program where IT wants, not the linker. ( of course, in my system, progs are NOT re-locatable, so memory swaping is prolly a lost cause, *sigh* segment pointers anyone?!?!)
Happy Hacking, Brett
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is copied from the developer forum:
The direct page register is not currently used by gcc on the CoCo, and it should be used.
John Malmberg was mentioning this with respect to floating point usage, and how we could use the direct page like the 68HC11 port does the zero page, as extra registers.
However, the question is, which page to use. Luckily, I have a somewhat straightforward answer:
The assembler in the tools we have includes a statement that will assure a set of data gets assembled on a direct-page boundary. We could, in the crt0 assembly code, include such a segment. The problem is, I'm not sure what happens when it gets around to linking.
Assuming we solve that (or it's not an issue), the crt0 would load the high byte of the address of that segment into the DP register. As long as the DP register isn't overwritten by called routines, everything should be fine, and we can just reference the soft-registers by their symbol names in the compiler, as the 68HC11 port does.
The DP clobbering is an issue, though, and so is figuring out if the direct-page segment gets linked in the right spot. Does anyone have any answers on this?
James
I think that using the DP register is definitely a possibility but I don't think that it should be turned on by default, especially when compiling with RSDOS.
If you intend on suporting or eventually supporting the the creation of ROF files there is already support in the file format for DP variables for both both initialized and uninitialize data. I wouldn't think that the assembler would be much of an issue since management of the DP is pretty straight forward but it might require a little tweaking. Since OS-9 loads the the module/program at the top of the userspace and places the data starting at $00 that might be a good default setting.
Now RS-DOS is a different story but the approach is about the same. My suggestion for this is to use the $FExx range for the DP register and under the RS-DOS crt0/runtime use as few bytes as necessary for standard crt0 data in that page. This will leave an extremely popular page of RAM available for anything time critical such as FIRQ music routines. You can also have multiple DP targets for RS-DOS with one being the DP set to #$FExx, one for $0000, and one that used extended addressing only.
In both cases if you choose to provide options within the compiler to automatically generate DP access I would reserve it for crt0 and for several byte and word values. Using it for dereferenced data or data greater than 2 bytes probably isn't necessary as access to those vars will most likely be off an indexed register rather than directly accessed.
Just a few thoughts...
...Chet...
Chet,
My idea was the reserve a part of crt0 (or crtn) as the extra "registers," about 32 bytes worth in total. This would be inside the executable image, which in RS-DOS would have to reside within &0C00-&7FFF, due to ROM issues. The libc I'd like to see come to light would use ROM routines for nearly everything.
My comment about the assembler was because I want to make sure that the section containing the 32 bytes starts at a 256 byte boundary, so that we can be sure it's all in the same page. I'd really rather leave &FExx alone.
Now, the purpose of this space is to emulate extra hardware registers. On the 6809, there's too small a number to be able to do floating point calculations, since up to three 32-bit registers would be needed at a time by the compiler. With the extra "registers", there's more space, and gcc will merge registers if there aren't any that can hold a value of a certain size alone.
It's not incredibly efficient to even be using DP variables for this purpose, and any other type of addressing would be even slower. These "registers" could be used at any time, and might be used frequently.
I'm likely to implement this for all targets, unconditionally. That way floating point support is available for everyone, all the time, and it might even be possible to integrate our changes into mainline gcc.
James
Chet, James,
I noticed the lack of DP indexing mode when playing around with gcc-m6809. If I'm not mistaken, I believe gcc simply allocates extra autovariables in the stack for the purpose of supplying extra "registers". Gcc seems to always use system stack pointer ( or maybe user stack, I don't remember) along with the 6809's indexed addressing mode to get at these "hidden" autovariables. I'm pretty sure there is different flavors of index addressing, including a 5, 8, and 16 bit offset opcodes. I'm assuming the as6809 assembler/linker chooses the best fit. These ops ( specially the 5 bit offset up ) aren't much slower then the Direct Page addressing mode. Is there really a need to include DP in gcc-m6809? I will re-look at the opcode and cycles for these commands as I know gcc-m6809 uses the stack/indexed autovariables A LOT. So maybe the DP would possibly save a lot of cycles over the length of a large program?
Also, I guess we must think of the ram savings too. most DP addressed ops require 2 bytes. where as the register-index addressed ops require more ram ( as follows ):
5 bit offset: 2 bytes ( opcode + 1 arg )
8 bit offset: 3 bytes ( opcode + 1 arg + 1 offset )
16 bit offset: 4 bytes (opcode + 1 arg + 2 offset)
note that the 5 bit's offset is encoded in the low bits of the 1st arg.
As a side note, if you're planning on compiling for RSDOS, I'm pretty sure any "system" calls ( including the 60hz timer interrupt of RSDOS ) requires the the DP be loaded with page 0x00 in order to work. I'm assuming there's way to get around this. Any sort of RSDOS libc would have to store/reset the DP prior to and after a system call. crt0 might have to replace the timer vector to code that replaces 0x00 in the DP, and then jump to the regular handler.
Another side note: I don't know much about OS9, but I'm pretty sure it requires special compiling/assem/linking, being that OS9 (as I know it) require all progs to be written in position independant code (PIC, using lot's of leax's). I don't think gcc/as09/ld09 does this yet. That's one of the reasons my own homemade linker doesn't do the final "absolute address" pass. It lets my bios add the proper base addresses to the linked executable, thereby allowing the bios/os to put the program where IT wants, not the linker. ( of course, in my system, progs are NOT re-locatable, so memory swaping is prolly a lost cause, *sigh* segment pointers anyone?!?!)
Happy Hacking, Brett