From: <rob...@gm...> - 2003-08-20 11:35:22
|
Greetings. I am attempting to compile code that consists of re-entrant functions and I also need to use the 256 byte external pseudo stack. sdcc --version returns: SDCC : mcs51/gbz80/z80/avr/pic14/pic16/xa51 2.3.5 (Aug 13 2003) (UNIX) I am compiling the code as follows: [thor@mithril robin]$ sdcc --debug test12.c --xstack ?ASlink-Warning-Conflicting sdcc options: "-mmcs51 --model-small --xstack" in module "test12" and "-mmcs51 --model-small" in module "_startup". ?ASlink-Warning-Conflicting sdcc options: "-mmcs51 --model-small --xstack" in module "test12" and "-mmcs51 --model-small" in module "_bp". ?ASlink-Warning-Conflicting sdcc options: "-mmcs51 --model-small --xstack" in module "test12" and "-mmcs51 --model-small" in module "_spx". I assume that I need to recompile the default sdcc libs with extra options, namely "--xstack". What changes do I need to make to the makefiles to re-compile the libraries with minimum pain ? Also, can I relocate the external pseudo-stack with --xstack-loc ? The question that arises then is that the global _spx is only 8bits wide and so only the first 256 bytes of the external RAM can be used. However if I recompile my code with --xstack-loc then I notice a new global called __page_no__. I am assuming that this would be used as a dph value with _spx in dpl therefore allowing access to the external 64k of xram using something like mov @dptr, r0 perhaps ?(paged external mem consisting of 256 pages of 256 bytes ?) The upshot is that even if I use --xstack-loc, I am not able to see the external stack relocated. Are there any pre-requisites I am missing or is this feature unimplimented ? Many thanks for an excellent tool. Cheers, Robin -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post |
From: <rob...@gm...> - 2003-08-20 19:03:45
|
Thank you Mr.Bernhard. With the help of your instructions I was able to rid myself of the warnings. I am trying to come up with a simple environment for running multiple threads in a round robin fashion with co-operative multi tasking on the 8051. For the same, it is quite imperative that the external RAM be used for the thread stacks. When I saw a "xstack-loc" feature I jumped since this would be a boon for me. From your reply I am assuming that this is probably a work in progress or has been shelved. :( (But the fact that a reference to a global called __page_no__ appeared in the map file when --xstack-loc was used made me feel that there was still hope, may I know what this global is for ?) As correctly pointed out by you, usage of : movx @r0, a or movx a, @r0 would compulsorily limit the user to using only the first 256 bytes of the xram as a stack. It occurred to me that if a special rule were made for the sake of "xstack-loc" which implied the generation of: movx @dptr, a or movx a, @dptr etc, then we would be in a position to access the external memory entirely. I would like to help with this. My domain is OS but if I could be given some pointers as to the code structure I would like to chip in to implement the "xstack-loc" feature as it would be very beneficial. From a cursory glance I find that the code for emitting asm code for various stack related operations is in gen.c but anything beyond this was, well, beyond me. Any pointers in this regard would be appreciated. Thank you, Robin -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post |
From: Bernhard H. <ber...@be...> - 2003-08-21 07:24:59
|
> From your reply I am assuming that this is probably a work in progress or > has been > shelved. :( There was already a suggestion to remove --xstack But Sandeep himself told us, that he stills plans to fix it up. His posting is from 2001-11-02 ... > (But the fact that a reference to a global called __page_no__ appeared in > the map > file when --xstack-loc was used made me feel that there was still hope, may > I know > what this global is for ?) grep shows me, that it's defined in device/lib/_spx.c, but there's no further reference in the whole source. > I would like to help with this. My domain is OS but if I could be given > some pointers > as to the code structure I would like to chip in to implement the > "xstack-loc" feature > as it would be very beneficial. > > From a cursory glance I find that the code for emitting asm code for > various stack > related operations is in gen.c but anything beyond this was, well, beyond > me. Any contribution to sdcc is welcome. Download the source and start digging. That's the way all sdcc-developers started. Bernhard |
From: Bernhard H. <ber...@be...> - 2003-08-21 14:15:18
|
> (But the fact that a reference to a global called __page_no__ appeared in > the map > file when --xstack-loc was used made me feel that there was still hope, may > I know > what this global is for ?) > > As correctly pointed out by you, usage of : > movx @r0, a > or > movx a, @r0 > would compulsorily limit the user to using only the first 256 bytes of the > xram as a > stack. > > It occurred to me that if a special rule were made for the sake of > "xstack-loc" which > implied the generation of: > movx @dptr, a > or > movx a, @dptr > etc, then we would be in a position to access the external memory entirely. I nearly forgot one point: you can do paging by "manually" setting P2. Have a look at _mcs51_genXINIT() in mcs51/main.c. You will have another big problem with --xstack, if you want to use xram not only for the stack. After each dptr access P2 must be reloaded. This is true, even if you're not paging. Bernhard |
From: Bernhard H. <ber...@be...> - 2003-08-20 13:55:10
|
> I am attempting to compile code that consists of re-entrant functions and I > also > need to use the 256 byte external pseudo stack. First of all: --xstack is very buggy. You've been warned. > [thor@mithril robin]$ sdcc --debug test12.c --xstack > ?ASlink-Warning-Conflicting sdcc options: > "-mmcs51 --model-small --xstack" in module "test12" and > "-mmcs51 --model-small" in module "_startup". > ?ASlink-Warning-Conflicting sdcc options: > "-mmcs51 --model-small --xstack" in module "test12" and > "-mmcs51 --model-small" in module "_bp". > ?ASlink-Warning-Conflicting sdcc options: > "-mmcs51 --model-small --xstack" in module "test12" and > "-mmcs51 --model-small" in module "_spx". > > I assume that I need to recompile the default sdcc libs with extra options, > namely > "--xstack". Yes. > What changes do I need to make to the makefiles to re-compile the libraries > with > minimum pain ? cd device/lib make PORT=xstack CFLAGS=--xstack objects After some files you'll get a fatal error from SDCC and a directory build/xstack. make PORT=xstack-auto CFLAGS="--xstack --stack-auto" objects You'll get a immediately an error. > Also, can I relocate the external pseudo-stack with --xstack-loc ? The > question > that arises then is that the global _spx is only 8bits wide and so only the > first 256 > bytes of the external RAM can be used. For stack access the opcodes "movx @r0,a" and "movx a,@r0" is used. Therefore only the first 256 bytes can be used. Bernhard |