Prog8 language and compiler topic

[desertfish]

9 hours ago, borgar said:

generally I find Prog8 to be a nice and simple language to work in. Since we are working closer to "the metal" than I normally do I think the simple types and limited syntax makes perfect sense. I especially like how easy it's to integrate in assembly functions with the Prog8 code.

Thanks, I am glad it is proving to be useful for others too in the way I intended it.

9 hours ago, borgar said:

I've already mentioned the issue with variables only used in assembly being optimized away. I'd prefer to have these in the Prog8 part of the code for a few reasons.

As long as you're not using zeropage locations you should be just fine by "inlining"  .byte or .word  statements in your asm blocks to reserve some variables space:

%asm {{

    lda  variable

    rts

variable  .byte 99

}}

 

I'm still considering a feature of some sort to mark variables to not optimize them away as unused, though.

9 hours ago, borgar said:

constants being removed in assembly output

This hasn't been the case anymore since the 6.5-beta version at least, so you may want to upgrade to that (or even better the recently published 7.0-beta version)

9 hours ago, borgar said:

debugging a bit more of a hassle

Yeah I'm not sure if prog8 compiler can be of any help for this for the Cx16 emulator.   It does output symbol and breakpoint lists for the Vice C64 emulator, but these are useless for the cx16 emulator.

Thanks for the feedback!

[borgar]

Ok, so I have a questions about adding larger sets of data in Prog8. Since the byte/ubyte data structures are limited to 256 bytes I have so far just split data into multiple arrays. That works well enough for now. However, let's say I want to update a full screen (40x25 for C64, more for CX16). It gets awkward to split this up into many arrays. 

It looks like perhaps %asminclude might be something but it's not obvious how to use this. I created a file



screen.asm



which contains my screen data :

screen_char

    BYTE    $20, $20, $20 ....

and include this in a module

screen {

  %asminclude "screen.asm", "screen"

  ...

}

and attempt to get hold of this label with something like

uword ref = screen.screen_char

without any luck (I tried various with and without various prefixes). According to the doc I should have access to the labels. I expect I'm doing something wrong but without any examples I don't know how to use this beyond this. 

[desertfish]

%asminclude is a bit broken at the moment, I now realize.

you could try %asmbinary?   if you prefix it with a label in the source code you should be able to refer to it from prog8

[borgar]

I tried this

screen {

testlabel:

  %asmbinary "data.bin"

  ...

}

but get the following error :

screen.p8:3:9: no viable alternative at input 'testlabel:'

[desertfish]

Defining a label at block scope (outside a subroutine) is only possible since the 7.0-beta release of Prog8.

Either upgrade your compiler or stick to labels inside of subroutines for now  (you can still refer to those perfectly fine by prefixing them with the subroutine name)

[desertfish]

Also you can now mark a variable as 'shared' with assembly code elsewhere, to not have it optimized away if even if you're not using it in prog8 code:

    ubyte @shared asmvar

 

[borgar]

8 hours ago, desertfish said:

Also you can now mark a variable as 'shared' with assembly code elsewhere, to not have it optimized away if even if you're not using it in prog8 code:



    ubyte @shared asmvar



 

Nice!

I guess I have to jump over to the 7 real soon. I was waiting for an official release of the new XC16 emulator, but there are so many updates now I'd like to use. I can always test using VICE for a while.

[desertfish]

Yeah I expected a new emulator release for quite a while already...

That said, I suspect most of the programs compiled by the new beta version of prog8 can work on the V38 emulator just fine.   The V39 changes were mainly in the ram/rom banking and some register changes.  If your program doesn't use these it will likely still work on V38 of the emulator. 

(oh and I think the floating point rom routines were relocated so you can't use floats if you want to do this)

[borgar]

3 hours ago, desertfish said:

That said, I suspect most of the programs compiled by the new beta version of prog8 can work on the V38 emulator just fine.   The V39 changes were mainly in the ram/rom banking and some register changes.  If your program doesn't use these it will likely still work on V38 of the emulator. 

And it turns out you are 100% correct here. For Petaxian the output from 7.0-beta compiler runs fine in the current compiler.

[desertfish]

I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2



This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes).



Some of the most important fixes/changes since the previous beta release:

• 
  string encoding and string interning bug fixes
  


• 
  various compiler crashes fixed
  


• 
  %asminclude fixed (scopelabel argument removed as well)
  


• 
  repeat loop code gen optimized some more
  

Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms.

Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work)



Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.