Prog8 language and compiler topic

[yock1960]

In 9.5 the gfx2 library had its screen mode numbering changed. I think I forgot to mention this in the release notes, sorry for that. This is the current list:

; SCREEN MODE LIST:
; mode 0 = reset back to default text mode
; mode 1 = bitmap 320 x 240 x 256c (8 bpp)
; mode 2 = bitmap 640 x 480 x 4c (2 bpp)
; mode 3 = bitmap 320 x 240 x 4c (not yet implemented: just use 256c, there's enough vram for that)
; mode 4 = bitmap 320 x 240 x 16c (not yet implemented: just use 256c, there's enough vram for that)
; mode 5 = bitmap 640 x 400 x 16c (not yet implemented)

This is likely the problem for older code no longer working with gfx2.

The compiler crash is pretty weird, I am quite sure I fixed the problem you had before in the 9.6 release. Ofcourse, there might be another new or different case. Do show some code that reproduces the problem so I can make a fix for it

Okay, I'll look at my gfx2 modes. As for the compiler crash, it appears to be related to 'when' blocks....not all when blocks. I've recently been looking at some of my whens, which can get pretty hairy...messy...and have thought about sending them off to subroutines, instead of having a bunch of code there....just moving the 'complexity'. I'll continue to whittle it down and let you know when I find something more concrete!

[yock1960]

Yep, using the new gfx2 screen modes works a treat! I was even able to use 9.5.1 to compile the problem program, which worked correctly. I may not have tried this previously, since I 'knew' the GUI code had issues under 9.5.1, but, I actually have two flavors of GUI now, one using gfx2 and the other using graphics, which saves about 2k now. The program that I was having problems with uses graphics. The graphics one is preferable due to the smaller footprint, but I was having a problem getting back to the correct text (shell) mode, that I believe I have figured out now. Of course...there is the fill command....only in gfx2, which I sometimes use....maybe the ROM routine will materialize one day.

I also 'discovered' the -varshigh option today! That is awesome! I used it to get one of my 'useless' programs to run from the shell environment at the default $4000 address. I have a 'special' stripped down version that I made for my own use, where I use $2100 for a load address, but being able to shoehorn it in for the default version is cool!

[yock1960]

Not 'when's. Here was the culprit: which I fixed by replacing the array style statements with @(var+n) = val, style notation.

sub cat(str s1, str s2) {
ubyte e1
ubyte e2
ubyte n

e1 = string.length(s1)
e2 = string.length(s2)


if s1[0] == 45 { ;-
for n in e2 downto 0 step -1 {
s2[n+1] = s2[n] }
s2[0] = 45
goto c1
}

if s1[0] == 43 { ;+
for n in 1 to e2 {
s2[n-1] = s2[n] }
}
else {
s2[e2] = s1[0]
s2[e2+1] = 0
}
c1:
}

[desertfish]

Thank you for the code snippet that triggers the bug. I will look into this soon to make a fix. Keep an eye out for updates here or on the discord

[yock1960]

Thank you for the code snippet that triggers the bug. I will look into this soon to make a fix. Keep an eye out for updates here or on the discord

I forgot to mention. The goto statement was there because there have been times when I couldn't get 'else' to work. I was able to use 'else' in 9.6.0, but maybe it has worked for a while now.

[desertfish]

"couldn't get else to work" is pretty vague, but the general rule of thumb is that if you find something weird in prog8 it's probably best to check if a new version of the compiler is available. Maybe even check a development version from github actions. Because small or large fixes are still happening all the time

[yock1960]

"couldn't get else to work" is pretty vague, but the general rule of thumb is that if you find something weird in prog8 it's probably best to check if a new version of the compiler is available. Maybe even check a development version from github actions. Because small or large fixes are still happening all the time

It kept coming up with a 'syntax' error message at else. Now on to my next problem! Sorry to be a PIA!

I'm writing a little analog clock app for the shell. I thought I was finished, but I hadn't checked all 24 hours. I just wrote a small sanity check app. The output doesn't match what I got from BASIC, something odd is happening for 9 through 11???

anngle_basic.jpg (94.92 KiB) Viewed 38329 times

angle.jpg (67.36 KiB) Viewed 38329 times

angle_output.jpg (97.57 KiB) Viewed 38329 times

[desertfish]

When you get a syntax error on the 'else', it's most likely that you made a mistake in the curly braces nesting earlier. Missing a closing brace somewhere, or having 1 too many.

The issue with the result in the numbers is because you have defined "hours" to be a byte type.
Multiplying it by 30 on line 44 will overflow it from 9 onwards (270 doesn't fit in a byte) and the result won't match the BASIC formula anymore. This is by design in prog8. If you want to fix it, just keep "hours" a word type , like "i"

Finally, it's cool that you found the kernal routine to print floats But you can also use "floats.print_f(number)" for that.

[yock1960]

When you get a syntax error on the 'else', it's most likely that you made a mistake in the curly braces nesting earlier. Missing a closing brace somewhere, or having 1 too many.

Maybe, hindsight now, but I was pretty sure not!

The issue with the result in the numbers is because you have defined "hours" to be a byte type.
Multiplying it by 30 on line 44 will overflow it from 9 onwards (270 doesn't fit in a byte) and the result won't match the BASIC formula anymore. This is by design in prog8. If you want to fix it, just keep "hours" a word type , like "i"

I thought casting to float would fix that...okay. Any chance on getting warnings for this kind of thing, it's bitten me more times than I care to admit!

Finally, it's cool that you found the kernal routine to print floats But you can also use "floats.print_f(number)" for that.

I know, I copied this code from a place that I was copying it to another string, not printing it.

[desertfish]

It's not possible to get warnings for possible overflows, that would mean ALL arithmetic operations would generate a warning. The compiler can't know the values that are multiplied (in this case). The cast to float is done AFTER the multiplication has been performed, because you put it in parentheses.

If you write it like this instead: "hour_angle = hour * 30 * ra" the problem also goes away because this does what you attempted.

It's an important way prog8 differs from other programming languages. I agree it can be jarring at first, but the language is designed this way to produce tight efficient code for the 6502 cpu. You were on the right track to cast the value to a larger type, which is the idiomatic solution to get rid of the overflows, you just had the parentheses in there that made the calculation happen before the cast.