Prog8 language and compiler topic

desertfish · Post by **desertfish** » Thu Dec 10, 2020 10:21 am

In the spirit of “eat your own dog food”

im finding those issues and tweaks (still am, currently) because I’m attempting to write some actually useful programs with it now. The text-elite game was one of the larger ones before, and currently I’m building an image file viewer. I even ran into a bug in one of the kernel functions that puts pixels on the screen so it is already pretty useful even if in the end nobody is going to use my image file format ?

if possible I also want to convert those image viewers that I mentioned in the koala demo topic. It would be pretty awesome if I can not only show those c64 koala picture, but also those nice Amiga IFF ILBM image files created by DeluxePaint ? And perhaps even other image formats. I want to see where the limits of this 8 bit system lie. Undoubtedly I’m also going to find more issues in Prog8 so no boredom for me

geek504 · Post by **geek504** » Fri Dec 11, 2020 5:48 pm

@desertfish awesome work! I sometimes wonder how you are able to dedicate so much time on your project! I have been away for a month or so due to graduate studies but I'm finally done for the semester and can now do some fun work on my compiler!

desertfish · Post by **desertfish** » Mon Dec 14, 2020 7:36 pm

Query

Prog8 has a built-in function mkword(msb, lsb) which creates a 16 bit word value from two bytes

In older versions the 2 bytes were in little endian order, analogous to how the word value would be stored in actual memory, so the lsb was first and then the msb. A couple of releases ago however I swapped the arguments around because I then thought it would be more readable like so: mkword($80, $22) = $8022 (in memory: $22 $80).

However it somehow doesn't feel right. I'm considering swapping the arguments again back to the old behavior so that would be like this again: mkword($22, $80) = $8022. (in memory: $22 $80)

What do you guys think?

Bones · Post by **Bones** » Tue Dec 15, 2020 10:40 am

Hiya @desertfish

How does the -emu flag work .. ? It looks like its trying to start the emulator but nothing happens .

EDIT! : Oh .. I see.. it needs to be in the path and then wants to load the rom files from

Starting Commander X16 emulator x16emu...

Cannot open /usr/share/x16-rom/rom.bin!

Never mind .. I just added a line into the build batch file :

java -jar d:\dev\commanderx16\prog8compiler.jar -target cx16 -emu test.p8

x16emu -prg test.prg -run

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

PS D:\Dev\Projects\prog8\cx16\test> .\build.bat

D:\Dev\Projects\prog8\cx16\test>java -jar d:\dev\commanderx16\prog8compiler.jar -target cx16 -emu test.p8

Prog8 compiler v5.3 by Irmen de Jong (irmen@razorvine.net)

This software is licensed under the GNU GPL 3.0, see https://www.gnu.org/licenses/gpl.html

Compiler target: cx16. Parsing...

importing 'test'

importing 'textio' (library)

importing 'syslib' (library)

importing 'conv' (library)

importing 'floats' (library)

importing 'math' (library)

importing 'prog8_lib' (library)

Processing for target cx16...

Optimizing...

Generating assembly code...

Creating prg for target cx16.

64tass Turbo Assembler Macro V1.55.2200

64TASS comes with ABSOLUTELY NO WARRANTY; This is free software, and you

are welcome to redistribute it under certain conditions; See LICENSE!

Assembling file: .\test.asm

Error messages: None

Warning messages: None

Passes: 5

Memory range: $0801-$0c3a $043a

Total compilation+assemble time: 0.406 sec.

Starting Commander X16 emulator x16emu...

PS D:\Dev\Projects\prog8\cx16\test>

desertfish · Post by **desertfish** » Tue Dec 15, 2020 11:31 am

Hello @Bones! Ah, I use Linux and while the compiler itself is portable, it seems that for starting the emulator I hardcoded some paths. I'll see if I can make this more OS-friendly in a future versoin, but it's low prio. Yes the emulator executable has to be in your PATH because it's not up to the compiler to figure out where it is installed (could be anywhere).

You can omit the -emu argument if you're starting the emulator yourself of course, it's just there for convenience so that you don't have to manually start it after a successful compile.

edit: seems like the -rom argument to launch the emulator is no longer necesarray on Linux too, so the next version of prog8 will have it removed. I think this should allow you to launch the emulator on windows then too with the -emu argument.

Greg King · Post by **Greg King** » Tue Dec 15, 2020 11:55 am

16 hours ago, desertfish said:

Prog8 has a built-in function mkword(msb, lsb) which creates a 16-bit word value from two bytes.

In older versions, the 2 bytes were in little-endian order, analogous to how the word value would be stored in actual memory, so the LSB was first and then the MSB.

A couple of releases ago however, I swapped the arguments around because I then thought it would be more readable, like so: mkword($80, $22) = $8022 (in memory: $22 $80).

However, it somehow doesn't feel right. I'm considering swapping the arguments again back to the old behavior, so that it would be like this again: mkword($22, $80) = $8022 (in memory: $22 $80).

Prog8 should insulate us from the very low-level, nitty-gritty details like that. We shouldn't care how the word is built; we should write the arguments in the order that we use when we think about 16-bit numbers. The same is true when we make 24-bit values. It will avoid a source of mistakes when we write programs.

desertfish · Post by **desertfish** » Tue Dec 15, 2020 12:36 pm

38 minutes ago, Greg King said:

the order that we use when we think about 16-bit numbers

So you're arguing to leave it as it is now, in the "natural" order. I can agree with that. (Notice that there's also lsb() and msb() functions that extract those bytes from a word, the reverse operation from mkword(). In a sense, they also already abstract the exact underlying byte order.)

desertfish · Post by **desertfish** » Tue Dec 15, 2020 10:10 pm

Released Prog8 5.4

- added the multi-format image file viewer example for cx16

- removed the rom path argument for launching the x16emu with -emu, should now work again on non-linux platforms

- improved several things in the diskio module, such as functions for incremental file loading

- implemented workaround subroutine for the FB_set_pixels bug (and made a PR for the ROM to fix it there too) commanderx16/x16-rom#179

- some other miscellaneous bugfixes and improvements. See the releases page on github.

Wow, it's been quite a ride to arrive at this version. I'm pretty happy with how everything turned out, but am now going to take a break and not work on Prog8 itself for a while. I think I now want to actually create things with it, rather than creating tools to make things. I really hope others will pick it up as well even if only to try it out for a bit. Feedback is invaluable and very much appreciated ?

desertfish · Post by **desertfish** » Sat Dec 19, 2020 2:32 am

I've added a short description on how subroutine calls are done in the code that Prog8 generates (that is, how are parameters and return values processed)

https://prog8.readthedocs.io/en/latest/technical.html

desertfish · Post by **desertfish** » Mon Dec 21, 2020 7:36 pm

For the next version I'm trying to add the 16 virtual CommanderX16 registers r0 - r15 to the language itself (or rather, the subroutine declaration syntax), so we don't have to do this anymore:


cx16.r0 = x1
cx16.r1 = y1
cx16.r2 = x2
cx16.r3 = y2
cx16.GRAPH_draw_line()

but instead can just write this:


cx16.GRAPH_draw_line(x1, y1, x2, y2)

The funny thing is, that this will also make those R0-R15 'registers' available on the C64 compiler target. So you can also make asm-subroutines there that can take additional parameters, instead of being restricted to just the A, X and Y register. Pretty nice.

(on the C64 these 'virtual' registers are not allocated in the zero page as on the Cx16, because there's no room for them there. So they will be slightly less efficient when used)