Prog8 language and compiler topic

All aspects of programming on the Commander X16.
yock1960
Posts: 136
Joined: Tue Nov 16, 2021 8:42 pm

Prog8 language and compiler topic

Post by yock1960 »


I think this must be a similar issue....and very strange, since as I say, my assembly code works as expected and I essentially inlined that code into the Prog8 source. I've added some 'unnecessary' instructions and have at least gotten it to react to button presses, but the x&y positions returned are garbage. 

yock1960
Posts: 136
Joined: Tue Nov 16, 2021 8:42 pm

Prog8 language and compiler topic

Post by yock1960 »


? Yeah, programmer error. ? Works now.

User avatar
desertfish
Posts: 1096
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Prog8 language and compiler topic

Post by desertfish »


I'm curious to your findings about the porting process. There's not many people using prog8 yet I think, so any and all feedback is precious! ?

yock1960
Posts: 136
Joined: Tue Nov 16, 2021 8:42 pm

Prog8 language and compiler topic

Post by yock1960 »


Yeah, I guess many people are using CC65, but as it doesn't natively support floating point (last I checked), I've never considered using it. Syntax is similar to many high level languages, so no issues there, other than what I personally would have with anything else...speaking as a non formally trained programmer. Other than my own bone-headed errors, I'm satisfied with my progress in porting the fractal program as a 'learning Prog8' task. Doing that program in assembly, which was a learning task in itself, took 4 months, albeit switching from the framebuffer routines, in order to use the entire screen, added some extra time at the end. This should go much faster. So far, the only thing that has caused me any heartache, is the limit on array size, which I worked around, by using multiple arrays...but it's a bit ugly. I could probably do an inline assembly routine....maybe...haven't thought about it too much...it's not a time critical part of the program and I'm trying to do as much as possible in Prog8 anyway. I would be happy if compiling generated the assembly listing from 64tass....a little thing...but it would keep me from having to load/assemble the .asm file again in order to get it. This will do a nice job as a replacement for Slang, which I used to do some BASIC porting for the C64 and CX16 back in early 2020, but floating point was broken for the CX16.  More feedback as it occurs to me!

User avatar
desertfish
Posts: 1096
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Prog8 language and compiler topic

Post by desertfish »


The array size limits are currently enforced because the code generator can only generate reasonable efficient code when it can use a single index register to get to the values. This means we can access 256 possible bytes in the array.  Which in turn means an array of words can contain 128 values max and an array of floats 256/5=51 values max.

What's your use case to have more than that number of values in an array?

(a possible workaround is as you described: use more than one array.   Or use a block of memory (see `memory()`) and access it via a pointer variable.)

I'll see if I can get 64tass to produce a listing file as well when it assembles.

edit: upcoming prog8 7.6  adds a "-asmlist" command line option to produce a listing file as well.

yock1960
Posts: 136
Joined: Tue Nov 16, 2021 8:42 pm

Prog8 language and compiler topic

Post by yock1960 »


Use case is arrays of 320 & 256 of floating point values that I pre-calculate for 'speed' ? for the madelbrot & julia set calculations. It's not a huge deal and as you say, I could rip the assembly code from my assembly program. A more serious issue is one I'm wrestling with now that I just can't get my hands around! I have a couple of lines of text that I popup at the top of the fractal dsiplay, the hires text printing that I adapted from a Youtube channel, has two variables that track x&y , much like printing from basic. You can change them to relocate, like print@, newline etc.. With the hires text printing that you include, they need x&y positions, so I am attempting to keep track in variables...only I keep getting bad results. See the attached screenshot, where I have built a test program to try and figure things out, but am not making much headway, since I don't understand the results!prog8.thumb.jpg.e0b59d178bb597f6630db96e879385ed.jpg

User avatar
desertfish
Posts: 1096
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Prog8 language and compiler topic

Post by desertfish »


It's hard to see in the image (blurry) but have you correctly terminated all strings by a 0 byte.

yock1960
Posts: 136
Joined: Tue Nov 16, 2021 8:42 pm

Prog8 language and compiler topic

Post by yock1960 »


Here is a test program that demonstrates an apparent issue with calculations, that I can't figure out. I have no problem in another program, but this clearly is not working here. There is also a difference between these calculations using  uwords & ubytes in some cases and in using a literal (8) instead of a variable defined as 8 here.
testp8.p8
User avatar
desertfish
Posts: 1096
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Prog8 language and compiler topic

Post by desertfish »


I have no idea what to look for @yock1960.  You'll have to provide a small reproducible example that shows what prog8 code is running , what results it gives, and what results you expected...

User avatar
desertfish
Posts: 1096
Joined: Tue Aug 25, 2020 8:27 pm
Location: Netherlands

Prog8 language and compiler topic

Post by desertfish »



Version 7.6 has been released  https://github.com/irmen/prog8/releases/tag/v7.6



Documentation as always here:   https://prog8.readthedocs.io/







  • added in containment check operator, this enables things such as if xx in [1,2,3] ... or if '@' in email_address ...


  • added experimental 'c128' compiler target to create programs for the Commodore-128


  • added a porting guide to the manual for efforts to port the language to other systems


  • added -asmlist argument to also generate a listing file as output


  • added -noreinit argument (experimental) to not create the reinitialization code for global variables. Can make programs smaller, but can also cause problems.


  • returnvalue of diskio.load() (and similar routines) has changed meaning: it's now just the last load address +1 (same as regular kernal's LOAD routine returns)


  • fixed position of @shared in variable declaration for array types


  • be a bit less verbose in similar warnings


  • several code generation optimizations


  • several bugfixes






Post Reply