asar icon indicating copy to clipboard operation
asar copied to clipboard

Feature Request: rompc(label)

Open spannerisms opened this issue 4 years ago • 4 comments

I'm not sure how feasible it is under the current architecture, but some function that gives the ROM address of a label regardless of the base it sits under would be very helpful, especially for the SPC in particular.

As an example, I use macros to organize data for my custom SPC engine, including taking care of labels and putting them in tables. Currently, I have to do stuff like this to make things work properly:

	pushbase
	base off

	pushpc
	org SPCEngine_start+SONG_POINTERS-ENGINE_TOP+!SONG*2
		dw <stitle>-4-SONGBANK!SONGBANK+!ARAM
	pullpc


	pullbase

That's because the only way to reference the label SONG_POINTERS that's built into my engine will give me the APU address. To add data to the table dynamically with macros, I need to be able to reference the ROM address of the data; i.e. where it's located before it gets transferred to the APU. I don't even remember what the pushbase accomplishes here, but I know I needed it for everything to work properly.

For this example specifically, I found it more useful to not use base, and instead use a pre-calculated offset to adjust the ROM address to an SPC address. The proposed feature would allow the use of base and simplify table-building macros such as this:

	pushbase
	base off

	pushpc
	org rompc("SONG_POINTERS")+!SONG*2
		dw <stitle>
	pullpc

	pullbase

The confusing verbosity of my issue could be best solved with a function that takes a label name as a string and spits out the ROM address to where it was ultimately written. So if I were to call rompc("SONG_POINTERS"), I would get back something like $C09817, even though the label itself normally would return something like $1000 from being in the APU.

This is just one example of the disgusting linguini I've needed to invent for things to work with table-building macros on the SPC.

spannerisms avatar Mar 13 '21 11:03 spannerisms

currently, labels are pretty much just numbers. they don't really keep track of where they came from. changing that would be quite a bit of effort and i'm not sure how useful it'd be. you can instead do something like

SONG_POINTERS:
pushbase
base off
SONG_POINTERS_PC:
pullbase

and use SONG_POINTERS_PC instead of rompc("SONG_POINTERS"), which i feel isn't that verbose and can do everything your proposed rompc function can.

trillllian avatar Mar 13 '21 11:03 trillllian

That's how I currently plan on refactoring, but it still kinda sucks. Anything that makes SPC stuff easier is good, so I figured it doesn't hurt to bring it up.

spannerisms avatar Mar 13 '21 12:03 spannerisms

One thing that could be added is a real_base function that simply returns the current absolute address. It wouldn't be able to act upon labels alone but it would allow something like this

SONG_POINTERS:
SONG_POINTERS_PC = real_base()

Something like that may be an improvement.

p4plus2 avatar Mar 13 '21 13:03 p4plus2

Added realbase as it could be handy. Open to improving this interface a bit more. But it is pretty well out of the question to allow labels as arguments without rewriting large parts of the asar internals.

p4plus2 avatar Mar 13 '21 13:03 p4plus2