move stack locations user defined about prog8 HOT 18 CLOSED

I've thought about this when I first implemented the various machine configurations inside the compiler, but have never actually encountered a use case to make them user definable until you raised this issue :)
It's a valid concern. Ideally you should be free to choose your own memory map. I'll think about this option.

from prog8.

That feels like a hack, but it might be an intermediate solution for this issue until a better one gets implemented. I'll see what i can do

from prog8.

Changed it in master branch!

I'll leave this issue open for now because I'm not sure that I want this to be the final solution, but you should be able to use it for now.

from prog8.

We'll have to change it for the other targets as well.
Also can't use only assembly level definition, really need the proper variable declarations in prog8 itself
So this actually requires a proper way to move the evalstack, not only a assembly level redefine.

from prog8.

So there is now the "-esa" option added to the master branch, that allows you to override the eval stack base address.
The compiler internally adjusts all locations of the virtual registers accordingly, if you're not compiling for the CommanderX16 ofcourse.

I think this is a good solution so am closing this issue now.

from prog8.

@brandonrobertz ok the table got processed a fair bit, but you can now find it in the Target System chapter in the manual.

I think what you added is really helpful. Thank you!!

from prog8.

Shouldn't be too hard to add an optional compiler flag to override it, but I also don't like having flags for everything under the sun...
Ah well, compilers are complex beasts so a dozen more command line flags shouldn't really scare users away? As long as they are all optional

from prog8.

probably. alternatively in my case it is to put the screen in
% 1110, 14: $ 3800- $ 3BFF, 14336, right below the stack. and then free 0400 for another use. this is a flag for advanced users.

from prog8.

I use bank 4 under the rom for graphics e000 and two screens to mix colors 167 (screen char). to speed up the plot I use pre-calculated tables. alternatively I will have to put a patch to those locations.

from prog8.

now that the define option works (-D),
does it is possible to make a small change to the code and insert the stack between two directives
(.weak .endweak), so that it can change them later.

.weak
P8ESTACK_LO = $ce00
P8ESTACK_HI = $cf00
.endweak
; -- user supplied symbols on the command line
BITMAP = $E000
P8ESTACK_LO = $fe00
P8ESTACK_HI = $ff00
; ---- basic program with sys call ----

regards

from prog8.

git pull !

from prog8.

I took a look at the library and the cx16 mapped registers follow the stack
below I'll post you a solution
however I think that the initial solution of the stack is perfect and in my case
it should only be changed the position of some pointers.
Not giving a chance to change the stack is probably best, but ...

syslib.p8

...
; they are allocated at the bottom of the eval-stack (should be ample space unless
; you're doing insane nesting of expressions...)
...

cx16 {

    ; the sixteen virtual 16-bit registers that the CX16 has defined in the zeropage
    ; they are simulated on the C64 as well but their location in memory is different
    ; (because there's no room for them in the zeropage)
    ; they are allocated at the bottom of the eval-stack (should be ample space unless
    ; you're doing insane nesting of expressions...)
    
    %asm {{

    r0 = P8ESTACK_HI + $0000
    r1 = P8ESTACK_HI + $0002
    r2 = P8ESTACK_HI + $0004
    r3 = P8ESTACK_HI + $0006
    r4 = P8ESTACK_HI + $0008
    r5 = P8ESTACK_HI + $000a
    r6 = P8ESTACK_HI + $000c
    r7 = P8ESTACK_HI + $000e
    r8 = P8ESTACK_HI + $0010
    r9 = P8ESTACK_HI + $0012
    r10 = P8ESTACK_HI + $0014
    r11 = P8ESTACK_HI + $0016
    r12 = P8ESTACK_HI + $0018
    r13 = P8ESTACK_HI + $001a
    r14 = P8ESTACK_HI + $001c
    r15 = P8ESTACK_HI + $001e
    
    r0s = P8ESTACK_HI + $0000
    r1s = P8ESTACK_HI + $0002
    r2s = P8ESTACK_HI + $0004
    r3s = P8ESTACK_HI + $0006
    r4s = P8ESTACK_HI + $0008
    r5s = P8ESTACK_HI + $000a
    r6s = P8ESTACK_HI + $000c
    r7s = P8ESTACK_HI + $000e
    r8s = P8ESTACK_HI + $0010
    r9s = P8ESTACK_HI + $0012
    r10s = P8ESTACK_HI + $0014
    r11s = P8ESTACK_HI + $0016
    r12s = P8ESTACK_HI + $0018
    r13s = P8ESTACK_HI + $001a
    r14s = P8ESTACK_HI + $001c
    r15s = P8ESTACK_HI + $001e
    
    r0L = P8ESTACK_HI + $0000
    r1L = P8ESTACK_HI + $0002
    r2L = P8ESTACK_HI + $0004
    r3L = P8ESTACK_HI + $0006
    r4L = P8ESTACK_HI + $0008
    r5L = P8ESTACK_HI + $000a
    r6L = P8ESTACK_HI + $000c
    r7L = P8ESTACK_HI + $000e
    r8L = P8ESTACK_HI + $0010
    r9L = P8ESTACK_HI + $0012
    r10L = P8ESTACK_HI + $0014
    r11L = P8ESTACK_HI + $0016
    r12L = P8ESTACK_HI + $0018
    r13L = P8ESTACK_HI + $001a
    r14L = P8ESTACK_HI + $001c
    r15L = P8ESTACK_HI + $001e
    
    r0H = P8ESTACK_HI + $0001
    r1H = P8ESTACK_HI + $0003
    r2H = P8ESTACK_HI + $0005
    r3H = P8ESTACK_HI + $0007
    r4H = P8ESTACK_HI + $0009
    r5H = P8ESTACK_HI + $000b
    r6H = P8ESTACK_HI + $000d
    r7H = P8ESTACK_HI + $000f
    r8H = P8ESTACK_HI + $0011
    r9H = P8ESTACK_HI + $0013
    r10H = P8ESTACK_HI + $0015
    r11H = P8ESTACK_HI + $0017
    r12H = P8ESTACK_HI + $0019
    r13H = P8ESTACK_HI + $001b
    r14H = P8ESTACK_HI + $001d
    r15H = P8ESTACK_HI + $001f
    
    r0sL = P8ESTACK_HI + $0000
    r1sL = P8ESTACK_HI + $0002
    r2sL = P8ESTACK_HI + $0004
    r3sL = P8ESTACK_HI + $0006
    r4sL = P8ESTACK_HI + $0008
    r5sL = P8ESTACK_HI + $000a
    r6sL = P8ESTACK_HI + $000c
    r7sL = P8ESTACK_HI + $000e
    r8sL = P8ESTACK_HI + $0010
    r9sL = P8ESTACK_HI + $0012
    r10sL = P8ESTACK_HI + $0014
    r11sL = P8ESTACK_HI + $0016
    r12sL = P8ESTACK_HI + $0018
    r13sL = P8ESTACK_HI + $001a
    r14sL = P8ESTACK_HI + $001c
    r15sL = P8ESTACK_HI + $001e
    
    r0sH = P8ESTACK_HI + $0001
    r1sH = P8ESTACK_HI + $0003
    r2sH = P8ESTACK_HI + $0005
    r3sH = P8ESTACK_HI + $0007
    r4sH = P8ESTACK_HI + $0009
    r5sH = P8ESTACK_HI + $000b
    r6sH = P8ESTACK_HI + $000d
    r7sH = P8ESTACK_HI + $000f
    r8sH = P8ESTACK_HI + $0011
    r9sH = P8ESTACK_HI + $0013
    r10sH = P8ESTACK_HI + $0015
    r11sH = P8ESTACK_HI + $0017
    r12sH = P8ESTACK_HI + $0019
    r13sH = P8ESTACK_HI + $001b
    r14sH = P8ESTACK_HI + $001d
    r15sH = P8ESTACK_HI + $001f

    }} 
}

from prog8.

I just ran into this issue and found it very unintuitive as to what was going on.

What happened was I was setting up the C64 memory map and couldn't get the second sprite location pointer working properly (I put VIC-II into bank 2 starting at $C000) and set up screen at $C800. This is a fairly common setup because it leaves a ton of room for both sprites and code. It took me a long time to figure out that the cx16.r0 variable was actually on top of my sprite pointers at the top of screen memory.

I think it could be helpful to explain some of this memory stuff somewhere, or at least include a documented example of a custom C64 memory map, because searching GitHub for "cx16.r0" was the only way I figured this out.

from prog8.

@brandonrobertz there is some described here https://prog8.readthedocs.io/en/latest/targetsystem.html but I agree it's not complete nor very easily accessible.

from prog8.

@brandonrobertz I'm planning to include the following diagram in the documentation. Would this clarify things enough for you?

from prog8.

Wow yes, that would be super helpful!

from prog8.

I'm still looking for the "clearest" way to write that table, maybe I'll put the comments as footnotes instead. But it will more or less be what is shown above

from prog8.

@brandonrobertz ok the table got processed a fair bit, but you can now find it in the Target System chapter in the manual.

from prog8.