Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.FUNCTION #3

Open
nicklausw opened this issue Apr 2, 2017 · 4 comments
Open

.FUNCTION #3

nicklausw opened this issue Apr 2, 2017 · 4 comments

Comments

@nicklausw
Copy link
Collaborator

I can't do dev right now so this issue is more a self-reminder than anything. (This, if implemented, could actually be merged into the original asm6).

ca65 lets defines double as functions like:

.define valplustwo(val) (val+2)

This functionality can be replicated in asm6 with:

.function valplustwo val
.return val+2
.endf

Used like lda #valplustwo(12).
This could be good for making fancy tables and stuff. Thoughts?

@freem
Copy link
Owner

freem commented Apr 2, 2017

For some reason, I thought this was going to be more like the .func/.endfunc from ca65.

In any case, I could see how this could be useful, even if I have no immediate use case for it myself.

@TheRealHamtaro126
Copy link

TheRealHamtaro126 commented Apr 10, 2017

For reference, This is how NESASM implents it,

CA65's equivelent (.define) is pretty similar... plain ASM6 has no equivelent.

So if we port ASM code, We have to manually figure it out... That isn't a good idea, So yes, Please implement this!

@nicklausw
Copy link
Collaborator Author

So I'm thinking this can be a simple find-and-replace job inside asm6 if .functions are just one-liners like the other assemblers.

I like this idea more than a full-on macro style thing like OP. Thoughts?

@nicklausw
Copy link
Collaborator Author

New planned functionality: .function bla(x,y) ((x>>4)<<y)

The plan is for asm6 to just scan for "bla" and eat white space to make sure the next symbol is '(', then work magic from there. Basically replace all occurrences with the expanded function.

My main concern is this might cause some redundant parser code in the program, and I've had some experience working on a program where that was the norm; it wasn't fun. Ideally, this is just a combination of existing functionalities making something new work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants