From: candido l. r. <c.r...@rc...> - 2008-12-27 15:07:58
|
Hello: Thanks for your help, This is the first time that I am using SDCC and I am having a couple of issues. (hope that this email is not too long) 1) The generated output ends in *.o, when I try to pass the objects to the linker it says that the type *.o is unknown, if I change the extension to *.rel it works 2) I tried to set the stack, code and memory, the stack is not set so points to 0x0000 rm -f /home/crodrigu/projects/debugger/CTC.adb rm -f /home/crodrigu/projects/debugger/uart.lst rm -f /home/crodrigu/projects/debugger/CTC.asm rm -f /home/crodrigu/projects/debugger/CTC.lst rm -f /home/crodrigu/projects/debugger/CTC.o rm -f /home/crodrigu/projects/debugger/CTC.sym rm -f /home/crodrigu/projects/debugger/debugger.o rm -f /home/crodrigu/projects/debugger/uart.adb rm -f /home/crodrigu/projects/debugger/uart.asm rm -f /home/crodrigu/projects/debugger/uart.cdb rm -f /home/crodrigu/projects/debugger/uart.ihx rm -f /home/crodrigu/projects/debugger/uart.lnk rm -f /home/crodrigu/projects/debugger/uart.map rm -f /home/crodrigu/projects/debugger/uart.o rm -f /home/crodrigu/projects/debugger/uart.sym rm -f /home/crodrigu/projects/debugger/debugger.adb rm -f /home/crodrigu/projects/debugger/debugger.asm rm -f /home/crodrigu/projects/debugger/debugger.cdb rm -f /home/crodrigu/projects/debugger/debugger.ihx rm -f /home/crodrigu/projects/debugger/debugger.lnk rm -f /home/crodrigu/projects/debugger/debugger.lst rm -f /home/crodrigu/projects/debugger/debugger.map rm -f /home/crodrigu/projects/debugger/debugger.mem rm -f /home/crodrigu/projects/debugger/debugger.sym rm -f /home/crodrigu/projects/debugger/debugger.rel rm -f /home/crodrigu/projects/debugger/uart.rel rm -f /home/crodrigu/projects/debugger/CTC.rel TOOL_BASE=/usr/local/bin $TOOL_BASE/sdcc --std-sdcc99 -mz80 --callee-saves-bc -c --debug /home/crodrigu/projects/debugger/uart.c $TOOL_BASE/sdcc --std-sdcc99 -mz80 --callee-saves-bc -c --debug /home/crodrigu/projects/debugger/CTC.c $TOOL_BASE/sdcc --std-sdcc99 -mz80 --callee-saves-bc -c --debug /home/crodrigu/projects/debugger/debugger.c cp /home/crodrigu/projects/debugger/uart.o /home/crodrigu/projects/debugger/uart.rel cp /home/crodrigu/projects/debugger/CTC.o /home/crodrigu/projects/debugger/CTC.rel cp /home/crodrigu/projects/debugger/debugger.o /home/crodrigu/projects/debugger/debugger.rel $TOOL_BASE/sdcc --xram-loc 0x1F40 --code-loc 0 --stack-loc 0x3e80 /home/crodrigu/projects/debugger/debugger.rel /home/crodrigu/projects/debugger/uart.rel /home/crodrigu/projects/debugger/CTC.rel |
From: Philipp K. K. <pk...@sp...> - 2008-12-27 18:53:46
|
candido lopez rodriguez schrieb: > Hello: > > Thanks for your help, This is the first time that I am using SDCC and I am > having a couple of issues. (hope that this email is not too long) > > > 1) The generated output ends in *.o, when I try to pass the objects to the > linker it says that the type *.o is unknown, if I change the extension to > *.rel it works Strange, works fine with the .o files for me. I usually use something like sdcc -mz80 --no-std-crt0 --code-loc 0x8080 --data-loc 0x7000 "../colecovision lib/bin/libcvu.lib" "../colecovision lib/bin/libcv.lib" "../colecovision lib/bin/crt0.o" *.o to link. > > 2) I tried to set the stack, code and memory, the stack is not set so points > to 0x0000 Hmm, AFAIK the stack points to 0xffff by default. It grows downwards. However I always use a custom crt0.o anyway. Philipp |
From: Richard G. <ri...@re...> - 2008-12-27 20:39:21
|
From memory, I think the Z80's SP=0 at reset, so the chances are that initialising of this register is something you're going to want to do fairly early on in your code. There are a couple of ways at least of doing this, but I use my own crt0.s file and the --no-std-crt0 compiler switch. The other way is to modify the standard crt0.s and replace it with your own version (overwrite the standard one), and let the compiler switch default. You /could/ use a piece of inline asm in your main() to set SP too, but this is not very elegant because main() is itself a function call which would have had it's return address pushed onto the stack, albeit uninitialised. I recommend writing your crt0.s (copy the standard one and edit it for your own purposes), and manually relocate it yourself in your own build. It might be useful for me to describe how SDCC handles Z80 initialisation - and this I have largely found out by experiment: The first to execute (from a reset) is crt0.s which will usually start at location 0x0000, the first three bytes will then be your reset jump instruction, probably a JMP to 0x0100 (labelled 'init'), and then a bunch of definitions of your various restart vectors. At location 0x0100 you will probably want to set important registers such as SP and any MMU registers if you're using one of the weird 'enhanced' Z80's. After this there is a gsinit section (which is empty in crt0.s), into which the linker relocates global variable initialisation code if need be. I have found that my init section doesn't appear in the linker's load map for some reason, but the code does appear in the eventual .hex file. Just a warning incase you're confused! -- Richard. PGP Key-id: 0x5AB3D350 Be free and open and breezy! Enjoy! Things won't get any better so get used to it. |
From: candido l. r. <c.r...@rc...> - 2008-12-27 22:45:39
|
On Saturday 27 December 2008 03:24:08 pm Richard Gray wrote: > >From memory, I think the Z80's SP=0 at reset, so the chances are that > > initialising of this register is something you're going to want to do > fairly early on in your code. > > There are a couple of ways at least of doing this, but I use my own crt0.s > file and the --no-std-crt0 compiler switch. The other way is to modify the > standard crt0.s and replace it with your own version (overwrite the > standard one), and let the compiler switch default. You /could/ use a piece > of inline asm in your main() to set SP too, but this is not very elegant > because main() is itself a function call which would have had it's return > address pushed onto the stack, albeit uninitialised. I recommend writing > your crt0.s (copy the standard one and edit it for your own purposes), and > manually relocate it yourself in your own build. > > It might be useful for me to describe how SDCC handles Z80 initialisation - > and this I have largely found out by experiment: The first to execute (from > a reset) is crt0.s which will usually start at location 0x0000, the first > three bytes will then be your reset jump instruction, probably a JMP to > 0x0100 (labelled 'init'), and then a bunch of definitions of your various > restart vectors. At location 0x0100 you will probably want to set important > registers such as SP and any MMU registers if you're using one of the weird > 'enhanced' Z80's. After this there is a gsinit section (which is empty in > crt0.s), into which the linker relocates global variable initialisation > code if need be. > > I have found that my init section doesn't appear in the linker's load map > for some reason, but the code does appear in the eventual .hex file. Just a > warning incase you're confused! Thanks for your help and quick response, I will initialize the stack pointer, the only problem that I see with SDCC is that the documentation is not generic, it refers to the main port and only in passing provides references about the remainder ports. This makes this the documentation a little confussing (well a lot :) Thanks again |