From: Hynek S. <ec...@ce...> - 2013-03-19 13:14:52
|
Hello, I want to start project with Z180 but I can't find some answers: - I get "ASlink-Warning-No definition of area HOME" but I don't know why - the code in .IHX file is placed at address 0x0020 (not 0x0000) - there is not default crt0 linked (i.e. SP setup etc.) - how to write bigger application using more than 64K memory? I am using SDCC 3.2.0a. My makefile: OBJS = boot.rel H = NAME = boot CFLAGS = -mz180 $(NAME).ihx: $(OBJS) sdcc $(OBJS) %.rel : %.c $(H) sdcc $(CFLAGS) -c $< -o $@ initial boot.c file: #include <z180.h> void main (void) { while (1); } output file boot.ihx: :0200200018FEC8 Thanks. Hynek |
From: Philipp K. K. <pk...@sp...> - 2013-03-20 20:15:02
|
On 19.03.2013 13:48, Hynek Sladky wrote: > Hello, > > I want to start project with Z180 but I can't find some answers: Here's a quick introduction to the Z180 port. When Lee proposed to make a Rabbit port, I had not created any any sdcc port before; so I thought doing a Z180 port first would be a good exercise. Also, I wanted to know, how minor instruction set differences would affect the quality of the generated code. So the Z180 port was created, with me doing the work on the compiler, and Lee doing the work on the simulator. For sdcc users this means: The current z180 port behaves as the z80 port, except for some differences in the generated code (it turned out that mlt makes for most of the differerence; the impact of tst and the instruction timings is rather minor). > - I get "ASlink-Warning-No definition of area HOME" but I don't know why I just compiled a trivial example: void main(void) { } with sdcc 3.2.1 #8452 on Debian GNU/Linux. I do not see this issue. I guess this is caused by your crt0 issue. > - the code in .IHX file is placed at address 0x0020 (not 0x0000) At address 0x0200. The only reason being that that was the default for the z80 port. You can change this using --code-loc. > - there is not default crt0 linked (i.e. SP setup etc.) Again, I do not see this issue. > - how to write bigger application using more than 64K memory? Depends on what you want to use it for. For functions, you'll have to roll your own solution for now, as the support in sdcc is AFAIK incomplete (again the same situation as in the z80 port). For variables, you can use named address spaces. Philipp |
From: Hynek S. <ec...@ce...> - 2013-03-21 09:27:24
|
Thanks for Your reply. after some more time of testing I got finally correct result. There was missing option for linker, so Z80 objects were linked as if they were for i51. It is probably also the cause for not linking crt0 and offset 0x0020 in IHX output (it was really 0x0020, not 0x0200; see IHX contents in my previous mail) I wonder why there is no warning/error: REL files contain target definition so I would expect it will warn me that I am linking wrong object files... I understand that I have to set bank registers manually but I have no idea how to write application which will generate code and/or access variables in another banks of memory. I used C compiler from Z-world company many years ago and memory banking was managed automatically; I expected that it could work here as well (just to set memory bank sizes and the rest is compiler's interest). So the last question still remains: is there any example how to write application for SDCC/Z180 which uses memory banking for code and/or data? Thanks. Hynek |
From: Philipp K. K. <pk...@sp...> - 2013-03-22 22:56:51
|
On 21.03.2013 10:27, Hynek Sladky wrote: > Thanks for Your reply. > > after some more time of testing I got finally correct result. There was > missing option for linker, so Z80 objects were linked as if they were > for i51. It is probably also the cause for not linking crt0 and offset > 0x0020 in IHX output (it was really 0x0020, not 0x0200; see IHX contents > in my previous mail) I wonder why there is no warning/error: REL files > contain target definition so I would expect it will warn me that I am > linking wrong object files... Weird, I did not see this issue. Can you check, if you can reproduced this in the nightly snapshot? If yes, please file a bug at Sourceforge and give details on your system (which OS, etc), since it seems to work for me. Feel free to also file a feature request about the warning in the linker. > > I understand that I have to set bank registers manually but I have no > idea how to write application which will generate code and/or access > variables in another banks of memory. I used C compiler from Z-world > company many years ago and memory banking was managed automatically; I > expected that it could work here as well (just to set memory bank sizes > and the rest is compiler's interest). > So the last question still remains: is there any example how to write > application for SDCC/Z180 which uses memory banking for code and/or data? I'll have a look at it in the next few days and try to come up with an example for data (and also have a look at implementing some more z180 code generation optimizations I thought about recently). Philipp |
From: Philipp K. K. <pk...@sp...> - 2013-03-24 21:41:37
Attachments:
test.c
|
On 21.03.2013 10:27, Hynek Sladky wrote: > So the last question still remains: is there any example how to write > application for SDCC/Z180 which uses memory banking for code and/or data? I don't have a Z180, so I didn't test. The attached example is a simple one for memory banking in the Z180 for data. It assumes CBAR has been set up correctly, and that you take care of the placement of the memory areas (you'll probably want to use linker options for that). In the example, functions that set BBR are defined, and named address spaces that use these functions (for bigger programs you'll probably want to place these functions in a different file, and only have the declarations and the address spaces in a header file; probably you'll also want to generate the function bodies using the preprocessor instead of writing them all by hand). Each named address space corresponds to one nak. Three variables are defined, one in each address space. When accesing these, sdcc will automatically insert the necessary calls to the functions that set BBR (and will only insert the minimum number of such calls necessary). Philipp |
From: Masur J. <jm...@bl...> - 2013-03-27 21:28:18
|
Hello, it really sounds incredible SDCC can do this automatically ! What if you call a function that itself call a function that will affect the bank switching ? Can SDCC detect such cases and do all the bank-switching automatically ? This really sounds incredible. If SDCC can do all this, it's one more reason to port it to the 6502 ! PS : What about interrupts that touches bank-switching ? Jonathan > > Three variables are defined, one in each address space. When accesing > these, sdcc will automatically insert the necessary calls to the > functions that set BBR (and will only insert the minimum number of such > calls necessary). > > Philipp > |
From: Philipp K. K. <pk...@sp...> - 2013-03-27 22:29:33
|
On 27.03.2013 22:28, Masur Jonathan wrote: > Hello, > it really sounds incredible SDCC can do this automatically ! > What if you call a function that itself call a function that will affect > the bank switching ? Can SDCC detect such cases and do all the > bank-switching automatically ? Well, sdcc does not do real interprocedural optimization. So unless the function is inlined, sdcc will assume that the state of BBR is unknown after the call. This could result in a write to BBR that is not necessary (but the function body might be in a different .rel file, so sdcc cannot know if the called function might change BBR; the only safe way is to assume that the state of BBR is unknown after the call). > This really sounds incredible. If SDCC can do all this, it's one more > reason to port it to the 6502 ! > > PS : What about interrupts that touches bank-switching ? You should either not access banked memory in the handler, or put code to save and restore BBR upon interrupts in your crt0.rel. Philipp |
From: Philipp K. K. <pk...@sp...> - 2013-03-27 22:28:07
|
On 27.03.2013 22:28, Masur Jonathan wrote: > Hello, > it really sounds incredible SDCC can do this automatically ! > What if you call a function that itself call a function that will affect > the bank switching ? Can SDCC detect such cases and do all the > bank-switching automatically ? Well, sdcc does not do real interprocedural optimization. So unless the function is inlined, sdcc will assume that the state of BBR is unknown after the call. This could result in a write to BBR that is not necessary (but the function body might be in a different .rel file, so sdcc cannot know if the called function might change BBR; the only safe way is to assume that the state of BBR is unknown after the call). > This really sounds incredible. If SDCC can do all this, it's one more > reason to port it to the 6502 ! > > PS : What about interrupts that touches bank-switching ? You should either not access banked memory in the handler, or put code to save and restore BBR upon interrupts in your crt0.rel. Philipp |
From: Masur J. <jm...@bl...> - 2013-03-28 22:42:46
|
Ok, therefore using automatic bankswitching should be done with caution, as it could potentially result in a ridiculous number of unnecessary BBR writes - say if I access a lot of variables in bankswitched area and call functions that doesn't touch BBR. For interrupts yeah it makes complete sense that the BBR should be saved/restored like any other register for that matter. Still it's nice to have this feature available if you know it's limits. Regards, Jonathan |
From: Philipp K. K. <pk...@sp...> - 2013-03-29 10:20:58
|
On 28.03.2013 23:42, Masur Jonathan wrote: > Ok, > therefore using automatic bankswitching should be done with caution, as > it could potentially result in a ridiculous number of unnecessary BBR > writes - say if I access a lot of variables in bankswitched area and > call functions that doesn't touch BBR. Well, we could do the following: Have a syntax for annotating function declarations with information on which bank will be active at function return (or at least make it possible to specify that the function doesn't change the active bank). This could then be used for all the functions in the standard library. And the information could be deduced automatically for functions in the same .c file that have been seen before by the compiler. I thought about having something like this for registers before: When the compiler knows that calling f() doesn't overwrite register de, we know that it doesn't have to be saved over the call. I'll open feature requests for these, so they won't be forgotten. Philipp |