-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.07.2014 04:16, Drew DeVault wrote: > Hi there! I am Drew DeVault, the primary maintainer of KnightOS: > > https://github.com/KnightOS/kernel > > It's a z80 operating system that runs on TI calculators. Currently, > both the kernel and userspace are written entirely in assembly. We > would like to provide support for C in userspace for the upcoming > release of kernel 0.7.0, and we would like to use SDCC for this > purpose. However, we have some difficulty. > > KnightOS relocates programs at runtime as they are executing, by > means of these macros: > > kcall(addr) ; RST 0x08 \ CALL addr kjp(addr) ; RST > 0x08 \ JP > addr kld(register, addr) ; RST 0x08 \ LD register, addr > > The restart at 0x08 relocates these by modifying the code to read > as such: > > NOP \ CALL absolute_address NOP \ JP absolute_address NOP \ LD > register, absolute_address > > Also supported is kjp(cc, addr) and kcall(cc, addr). Of course, > this only affects references that live inside the running > executable. > > The ideal solution to this problem would be for SDCC to be aware of > this paradigm and to directly emit compliant assembly. Since SDCC > cannot currently do that (or at least we don't think it can), we > are considering some alternative options. The one we currently have > in mind is processing the assembly source before the assembler gets > to it, but this has the potential issue of screwing up relative > jumps (which can only jump a maximum of 127 bytes in either > direction). Manipulating assembly source like this is also just a > crappy solution in general, so we'd like to find something else. > > Do you folks know of a good way we can solve this problem? Is this > something SDCC could be extended to support, or are we better off > figuring out an external solution?
I see two options: 1) sdcc rarely emits jr directly (jr is mostly generated in the peephole optimizer), so by using a non-default peephole rule file (see pepph-z80.def), one could probably get around the jr issue (or you could just change jr back to jp in you processing of the assembly source). With the runtime relocation your OS uses and the additional nops inserted you don't seem to care much about efficiency anyway. 2) Make sdcc emit your macros instead of jp / call / ld. This would be relatively easy for jp and call, since they are only emitted from a few places, but harder for ld. You might want to have a look at z80/gen.c. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlPh2OMACgkQbtUV+xsoLpoBFACfZqAIH79mRIrnwW2btoI0GKHr iyQAn3X+YDJ0xsNaxsPgVoVMFI0Ok45e =XNdQ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
