You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a block directive, defined functions would get consecutive addresses, counting from the indicated xxxx. A block directive, applied before the definition of UNIT would allow to specify where the library would be compiled. It might not even be necessary to enclose it - that would be sufficient.
Recursion of {$ORIGN} directives - this is already a matter for discussion :) but I don't hide that it would be welcome :)
It would be possible to compile a part of the routines, e.g. under ROM, where it is also possible to run it - with restrictions, but still. Possibility to build dynamic libraries - of course, after adjusting the rest of the code accordingly.
You could also extend the above idea, not just to code: consider variables and the possibility to allocate them in any space in RAM by defining:
{$VARORIGIN $1000}
var a:byte;
b:String[40];
...
{$ENDVAR}
I know that a similar situation can be achieved by using the absolute modifier, but this would give a bit more "slack" in the code, and the possibility of assigning a default value, which can't be done now by using absolute.
The text was updated successfully, but these errors were encountered:
Extended memory banks when allocating using the {$ORIGN} directive.
For the moment, I would be willing to put the fact of taking care of the issue on the shoulders of the programmer/user:
loading into a bank
switching that bank
and restoring it.
It seems to me that everyone can have their own vision of how to do this - as long as they want to :) Maybe, in time, some interesting concept will be worked out, which can be permanently adopted in MAD Pascal :)
I point out that, I just wanted to raise this topic and I know that it will be (very) difficult to implement. It's an ambitious topic, with a lot of possibilities, but I think that for the time being, it can be somewhat "bypassed"
The fact that when possibly introducing such functionality - to make it easier - it's worth thinking at least a little bit about the suggested {$ORGIN} directive - because why re-write later, although.... it can be different :P ;)
Uh oh!
There was an error while loading. Please reload this page.
It would be nice to be able to specify from the source code level for procedures where they should be compiled. I see my proposal as follows.
Origin xxxx
, where xxxx, would be the address in memory.{$ORIGIN xxxx}
and{$ENDORIGIN}
.In a block directive, defined functions would get consecutive addresses, counting from the indicated
xxxx
. A block directive, applied before the definition ofUNIT
would allow to specify where the library would be compiled. It might not even be necessary to enclose it - that would be sufficient.Recursion of
{$ORIGN}
directives - this is already a matter for discussion :) but I don't hide that it would be welcome :)It would be possible to compile a part of the routines, e.g. under ROM, where it is also possible to run it - with restrictions, but still. Possibility to build dynamic libraries - of course, after adjusting the rest of the code accordingly.
You could also extend the above idea, not just to code: consider variables and the possibility to allocate them in any space in RAM by defining:
I know that a similar situation can be achieved by using the
absolute
modifier, but this would give a bit more "slack" in the code, and the possibility of assigning a default value, which can't be done now by usingabsolute
.The text was updated successfully, but these errors were encountered: