Skip to main content

@wim_v12e Spotted a pretty awful bug with Beetbug this morning, I've fixed it. It passes the opcode test again, sorry :bloat:
@WimⓂ️
Unknown parent

Devine Lu Linvega
Devine Lu Linvega
• •
@winnie listening to SPFDJ's set at Boiler Room. 15ish minutes in
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
By using Beetbug, I found one of the reasons I use more RS than needed. It's because Funktal does not have even rudimentary tail call optimisation. Next thing to fix ^_^
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •
That's a good one to tackle. JSR2 + JMP2r = JMP2
This entry was edited (1 year ago)
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
Yes, and it's nice to have an immediate syntax for it as well.
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •
The immediate modes don't use absolute addresses tho, they are written in memory as a relative short. So if you plan on doing it this way, you'll have to get the offset. Not that it would be too difficult or anything, but just thought I'd mention it.
This entry was edited (1 year ago)
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
How's that? Say I have a function @f1 and I say !f1, does that do the equivalent of JMP? The code I generated,where I replace f1 JMP2r by !f1 , seems to work ok.
This entry was edited (1 year ago)
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •
;label JMP2 is PC = ;label
JMI label is PC += label

The short value of the label in the screenshot is 0x0118, the short value of the jsi is 0x0011
This entry was edited (1 year ago)
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
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 ?
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •
OOOooh, wait. Are you generating uxntal, that you're then assembling with uxnasm/drifblim? Or are you going straight from fortrant to bytecode?
This entry was edited (1 year ago)
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
I generate uxntal, that is much easier for development and debugging. You have all the tools for going to bytecode.
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •

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.

charlie

2023-04-04 16:16:02


Ad-hoc structs in Uxntal

#uxn


#uxntal @charlie
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
@bellinitte I hadn't seen that. That looks like a cool way to statically allocate memory, I will definitely keep it in mind.
@charlie
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
Is the purpose of the .rom.sym files to allow to link roms?
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
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.
in reply to Devine Lu Linvega

WimⓂ️
WimⓂ️
• •
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.
in reply to WimⓂ️

Devine Lu Linvega
Devine Lu Linvega
• •
Oh! yes, the format is pretty limited. It won't be able to do this sort of gymnastics yet.

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.

⇧