Prog8 language and compiler topic

[borgar]

I have upgraded to BETA2 and Petaxian runs fine I can now use the Prog8 const from my assembly which is excellent.

However, I'm still struggling with figuring out how to import raw data. I.e. I want to add full screen char data either as binary or as asm code. AND access this from Prog8. All I basically need is a way to figure out the address to the first byte of this data. Right now I can not e.g. see any way that %asmbinary is even useful. You mentioned using a lable but I can't get this to work. This might not be a bad idea to add an example for this btw.

In any case I'm trying something like this:

main {

rawdata:

  %asmbinary "data.bin"

  sub start() {

    uword charPtr = &rawdata

    charPtr++ ; Only to prevent removal of variable during compile

  }

}

but get the following error

.\screen_test.asm:57:9: error: not defined ident '_rawdata'

        lda  #<_rawdata

               ^

.\screen_test.asm:43:1: note: searched in this object only

 start  .proc

 ^

[desertfish]

hm, that looks like a scoping bug in the compiler.  I'll see if I can fix that.

In the meantime, can you try to replace &rawdata with &main.rawdata ?

[borgar]

2 hours ago, desertfish said:

In the meantime, can you try to replace &rawdata with &main.rawdata ?

Using the namespace prefix gives me

.\screen_test.asm:57:9: error: not defined ident '_main'

        lda  #<_main.rawdata

               ^

.\screen_test.asm:43:1: note: searched in this object only

[desertfish]

Yeah okay, so we have several issues with assembly symbol name scoping in the code generator. This is now on top of the list of the remaining things to fix for the final 7.0 release ?

[desertfish]

I believe the assembly symbol scoping issue has been resolved.

[borgar]

Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input.

Many thanks.

 

[desertfish]

... unfortunately another asm symbol scope issue now cropped up. I'm not done yet

[desertfish]

Poll.

I'm contemplating reverting the Cx16 V39 changes that I have already made in Prog8, for the upcoming 7.0 release -- because the actual release of an official v39 emulator+roms is taking way longer than I anticipated.

1. 
   keep v39 support in Prog8 as it is. You're targeting  v39 already and can run it with a custom build of the emulator+roms as they are now on github
   


2. 
   revert back to v38 support because that is still the official cx16 release    (and put the v39 changes back in once the official cx16 release is there)
   


3. 
   make it selectable via a command line switch
   

Which option would you choose and why?

[Scott Robison]

I've not looked at your project to know how possible this would be, but are the differences so onerous that you really can't do #3? Or even #4: Have the runtime select v38 or v39 based on the ROM version at runtime?

I know, it's really easy to say "why not" when you have no idea what the code looks like.

[desertfish]

Good questions.  There's no runtime though: prog8 compiles down to machine code in the end, and while doing so it makes various assumptions about the target platform (cpu type, memory mapped i/o registers, and rom routine locations). For example the memory locations of the floating point routines in rom -which prog8 uses for its float types- have changed between v38 and v39 roms and this will make compiled programs crash when run on the other rom version.

So basically, allowing for a compiler switch more or less requires introducing a third target machine definition in the compiler something which is pretty involved and is potentially going to duplicate a lot of code and library files.

Apart from that, on the discord it was correctly pointed out that it would also introduce the expectation of backward compatibility,  which is complexity that I'm not wanting to go for.