After this conversation with Miau about function parameters, I started to think a little bit about the subject. I'm sorry but this message will be like a brain storming session but I hope that some interesting ideas will comes up out of it.
The biggest problem with temp variable is that you may re-use by accident the same variable. So what I'm thinking is why not trying to emulate what is done in higher level language like C to avoid those issues? I don't know how much will be the cost on performance but here's the concept, which I have to put in code later based on the message and clean up after.
I always under use the stack so why not use it like it should be? Before calling a function, you would have a macro lpr (Load ParameteR) that will stores the parameters on the stack.
ex: lpr myFunction(param1, param2) etc.
Now param1 and 2 are on the stack. The macro will be in charge of (in that order):
- storing the localVariable/frame pointer on the stack (explained later)
- putting the variables on the stack
- calling the function
- clean up once the function is finished (means restoring localVariable/frame pointer and unpop parameters)
Once I call the function, I will have my parameters and the return address on the stack. Now that I'm inside the function, I must get a copy of the stack pointer and store it in a variable, the frame pointer.
To access my parameters, I must define some constant to locate the position of the parameter. The only drawback I see is that each constant must be unique. Maybe some fancy trick with scoping could fix that issue.
param1 = sizeOfFunctionAddress + sizeOfVariable
param2 = sizeOfFunctionAddress + param1 + sizeOfVariable
Maybe order is wrong, for now let's say it's right. So if I want to access my parameters, I could define a macro that use my frame pointer variable. hmm.. the real code in the macro would look something like:
ldx framePointerAdr + param1
will get me the first parameter.
Now that my function parameters are handled I may want to have some local variable too. So when I enter the function, I must define right away all my local variables on the stack. A macro could do the job. The only drawback again is the constant for the variable location must be unique. Once the variable are defined, I must get the stack pointer again and save it in the LocalVariable pointer variable. With LocalVariable and defined constant I can access all my local variables on the stack.
I don't have to worry about the content of the frame/LocalVariable pointer when I call a function since the macro will take care of saving them on the stack and restoring it at the end.
Basically, this is the concept I thought tonight very fast. I don't know how pratical and fast it is yet but it seems interesting and it may fix the issue Miau have with parameters. My only concern is the constants for parameters, how to handle them. I must figure out a solution. If scoping can take care of it that could be a solution. Must make a proof of concept to see how it goes.
Does what I say make sense? All what I said is theoretical and based on some ideas on how stack work for higher level language. It seems something you could do with some macro in ca65.
Any comment on the subject will be appreciated.
The biggest problem with temp variable is that you may re-use by accident the same variable. So what I'm thinking is why not trying to emulate what is done in higher level language like C to avoid those issues? I don't know how much will be the cost on performance but here's the concept, which I have to put in code later based on the message and clean up after.
I always under use the stack so why not use it like it should be? Before calling a function, you would have a macro lpr (Load ParameteR) that will stores the parameters on the stack.
ex: lpr myFunction(param1, param2) etc.
Now param1 and 2 are on the stack. The macro will be in charge of (in that order):
- storing the localVariable/frame pointer on the stack (explained later)
- putting the variables on the stack
- calling the function
- clean up once the function is finished (means restoring localVariable/frame pointer and unpop parameters)
Once I call the function, I will have my parameters and the return address on the stack. Now that I'm inside the function, I must get a copy of the stack pointer and store it in a variable, the frame pointer.
To access my parameters, I must define some constant to locate the position of the parameter. The only drawback I see is that each constant must be unique. Maybe some fancy trick with scoping could fix that issue.
param1 = sizeOfFunctionAddress + sizeOfVariable
param2 = sizeOfFunctionAddress + param1 + sizeOfVariable
Maybe order is wrong, for now let's say it's right. So if I want to access my parameters, I could define a macro that use my frame pointer variable. hmm.. the real code in the macro would look something like:
ldx framePointerAdr + param1
will get me the first parameter.
Now that my function parameters are handled I may want to have some local variable too. So when I enter the function, I must define right away all my local variables on the stack. A macro could do the job. The only drawback again is the constant for the variable location must be unique. Once the variable are defined, I must get the stack pointer again and save it in the LocalVariable pointer variable. With LocalVariable and defined constant I can access all my local variables on the stack.
I don't have to worry about the content of the frame/LocalVariable pointer when I call a function since the macro will take care of saving them on the stack and restoring it at the end.
Basically, this is the concept I thought tonight very fast. I don't know how pratical and fast it is yet but it seems interesting and it may fix the issue Miau have with parameters. My only concern is the constants for parameters, how to handle them. I must figure out a solution. If scoping can take care of it that could be a solution. Must make a proof of concept to see how it goes.
Does what I say make sense? All what I said is theoretical and based on some ideas on how stack work for higher level language. It seems something you could do with some macro in ca65.
Any comment on the subject will be appreciated.