Page 18 of 39

Prog8 language and compiler topic

Posted: Mon Dec 27, 2021 9:38 pm
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. 


Prog8 language and compiler topic

Posted: Mon Dec 27, 2021 10:56 pm
by yock1960

? Yeah, programmer error. ? Works now.


Prog8 language and compiler topic

Posted: Tue Dec 28, 2021 12:00 am
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! ?


Prog8 language and compiler topic

Posted: Tue Dec 28, 2021 7:57 pm
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!


Prog8 language and compiler topic

Posted: Wed Dec 29, 2021 9:30 am
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.


Prog8 language and compiler topic

Posted: Fri Dec 31, 2021 5:15 pm
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


Prog8 language and compiler topic

Posted: Sat Jan 01, 2022 12:11 pm
by desertfish

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


Prog8 language and compiler topic

Posted: Mon Jan 03, 2022 1:11 am
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

Prog8 language and compiler topic

Posted: Tue Jan 04, 2022 8:00 pm
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...


Prog8 language and compiler topic

Posted: Tue Jan 04, 2022 8:03 pm
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