Gregory's Server@neauoire OK, I understand that bit. But I don't understand why I would need to get the offsets at compile time to do the tail call optimisation. Is it not correct to do
label JMP2r => !label ?
|
12 comments
  @wim_v12e aaah, then yes, nothing to worry about there then. I'm not sure if you've seen @bellinitte's padding mod to #uxntal (https://merveilles.town/@bellinitte/110141437531968122) but you miiight be able to make use of this somehow. @neauoire @bellinitte I hadn't seen that. That looks like a cool way to statically allocate memory, I will definitely keep it in mind. @wim_v12e specs: https://wiki.xxiivv.com/site/symbols.html you can seen an implementation of the symbols finding routine here: https://git.sr.ht/~rabbits/beetbug/tree/main/item/src/beetbug.tal#L683 @neauoire OK, I see. So that information should be enough to link a label to an address. What would be needed for linking would be to add a fixed offset to all absolute addresses in a rom. @neauoire Sorry, I didn't provide enough context. Suppose you have an tal program and you call a function that is not defined in the source code, but you have a .rom and .rom.sym for it. From the .rom.sym you can get the address for the label, but that will in general not work because you need to combine the roms for both. So you'd need to apply some offset to the rom so that its content fits after the content of your source file. For that you'd need to know at which address your source ends. @wim_v12e Oh! yes, the format is pretty limited. It won't be able to do this sort of gymnastics yet. |
@wim_v12e OOOooh, wait. Are you generating uxntal, that you're then assembling with uxnasm/drifblim? Or are you going straight from fortrant to bytecode?