Prog8 language and compiler topic

[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!

[desertfish]

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

[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

[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...

[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

[ZeroByte]

On 12/27/2021 at 11:53 AM, desertfish said:

I have not yet worked with the mouse on the x16, but perhaps there is something similar going on?   If not, all I can say is compare the resulting assembly code from prog8 to your own code and try to discover where the difference occurs.   The easiest way to do this is by making a minimal reproduction program

The mouse in X16 is janky. It only returns screen X Y positions and buttons. (i.e. no dX dY options) and it coopts sprite 0 even if you don't want to have a pointer on the screen. You can specify a blank sprite as sprite0 as the graphic for the pointer, but sprite 0 will be positioned at the X,Y the Kernal wants it to be. Whenever I get zsound to the point where I push it out the door, I might get back on my widget library I was working on, where I planned to counter this by making the engine hide the kernal pointer and move it back to the middle of the screen on each frame so you won't ever run into the edge of the screen and not be able to continue moving the mouse in that direction.

[desertfish]

Version 7.7 has been released!   https://github.com/irmen/prog8/releases/tag/v7.7

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

• added pipe operator |>
• added new syntax for string encodings, and added iso: encoding
• on cx16: added txt.iso() to switch to iso charset
• added @requirezp flag on variables to force them in Zeropage
• added pokemon() function
• fix assembly <-> prog8 label referencing issue (labels in asm no longer start with underscore)
• less aggressive dead code (variables) removal
• fixed some type casting issues
• several small code gen optimizations
• fix broken code generated for certain equality comparison expressions
• several other bugfixes.

[Ed Minchau]

On 1/19/2022 at 2:09 PM, desertfish said:

added pokemon() function

Gotta catch them all.

[borgar]

It's so nice to see so much regular progress for Prog8.

BTW, I first encountered a language with "piping" syntax during my university days. That was in the BETA programming language (https://en.wikipedia.org/wiki/BETA_(programming_language)). There is looked like this

(* x = 1 *)
1 -> x ;

(* x = f(1)  *)
1 -> f -> x ;

(* res = fibonacci(1,5)  *)
(1,5) -> fibonacci -> res;

Multiple parameters was supported and "safe" so that

(x, y) -> (y, x)

did a "swap".

This syntax is a lot easier read for long functions chains but I have to admit that I never got 100% comfortable with this syntax style. I guess the traditional Algol syntax was already firmly embedded in my skull by the time I encountered BETA.

[desertfish]

pokemon(address, value)

Attempts to write a byte to a ROM at a location in machine language monitor bank. Doesn’t have anything to do with a certain video game.

 

because writing to rom is not possible the function effectively does nothing and is implemented as such

 

 

 

[desertfish]

@borgarthe pipe was or is a bit experimental. It’s inspired by the pipe operator in f#. The implementation can perhaps be used later to serialize nested expressions, thereby avoiding the slow stack based approach. But it lacks some features to do this now

[desertfish]

  Version 7.7.1 has been released that fixes a bunch of compiler crashes.  https://github.com/irmen/prog8/releases/tag/v7.7.1

[desertfish]

  Version 7.8 has been released   https://github.com/irmen/prog8/releases/tag/v7.8

• removed old @"screencodes" string encoding syntax (use sc:"hello" instead)
• library API change: moved cx16.vload() to cx16diskio module
• API change: added alignment parameter to memory() function
• library API change: string.find now returns index of character + carry bit status (instead of substring address)
• completely rewritten variable allocation, resulting in large program size savings
• diskio.list_files() now has a larger buffer to be able to list larger directories
• restructured code generator and added -expericodegen command line flag to select alternate experimental code generator (only a stub at the moment)
• tweak compiler output to be less noisy
• various bugfixes and optimizations

 

[desertfish]

  Version 7.9 has been released  https://github.com/irmen/prog8/releases/tag/v7.9

• added atari compilation target, to create programs for the Atari 800XL. It's very rudimentary still.
• breaking syntax change of the pipe operator |> : the functions in a pipe now have to be actual function calls (without the first argument specified), rather than just the function names
• breaking change of the pipe operator |>: you can no longer use a variable at the end to store the value into. Just use an assignment instead.
• sys.memcopy and sys.memset on the cx16 target no longer depend on kernal routine so now work even when the kernal is not banked in.
• fix program crash bug caused by non-inlined asmsub not having a proper RTS instruction.
• fixed compile time calculated constant results of sin() and cos() functions to now be identical to their runtime counterpart
• better searching for used variable names inside assembly code so unused variable elimination is smarter
• properly report duplicate label names
• properly report invalid text encoding selection
• properly report in check against non-constant range
• many internal refactorings in the code generator as ongoing attempts to make it easier to change/replace

 

[KennethWilke]

Wow, this is very impressive work! I need to put this in my queue of things to tinker with

I wrote a 6502 assembler a long while back but never did anything more with it.

Edited March 11 by KennethWilke

[desertfish]

@KennethWilke prog8 was created for the Commodore-64 but then I was introduced to the X16 which massively spiked my motivation to work on it

[desertfish]

  Version 8.0 has been released   https://github.com/irmen/prog8/releases/tag/v8.0

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

A new major version release to commemorate the long awaited official "r39" release of the Commander X16 emulator and kernal roms.
Some fundamental changes were made there that had to be reflected in Prog8's cx16 target and libraries.

For current cx16 development, prog8 8.0 is required. Older versions won't work properly anymore.

Changes:

• support for the official r39 commander x16 release (new Vera memory layout, changes to rom routines, etc.)
• updated cx16 examples to new routines
• breaking syntax change: ** operator has been removed. Use floats.pow() instead.
• make '&&' a parser error instead of treating it as bitwise and followed by address-of
• library API change: moved pattern_match() from prog8_lib to string module
• fixed string encoding for escaped characters
• fixed bug in codegen for containment check in bytearrays and strings
• fixed error for certain typecasted expressions inside comparisons
• fixed return type error for asmsubs with >1 result values
• [internal] new simplified Ast meant to build better code generators on in the future
• [experiment] new 'virtual' target and built-in VM to compile prog8 programs for
• [experiment] new syscall builtin function to interface with the VM

 

Edited April 2 by desertfish

[desertfish]

I've decided to remove the plethora of integer trig builtin functions (sin8u, cos8u, ...) in the next prog8 version.

My expectation is that if you need to use trig functions, that a tailor made implementation for your program is better than the general functions that prog8 used to provide.

I think I'll move the old builtin functions into a regular library module instead, if you really want to use them.

[rje]

A library module would be nice, since my custom trig things are neither particularly usable nor documented, so...

Looking over the stuff prog8 has, plus my using C for the past year for the X16, has finally started to pique my interest.

 

[desertfish]

They will get a place in the (existing) math module, as regular subroutines this time.

So the only thing that older code has to change, is prefixing them with "math." and then it will continue to work.

[borgar]

I've had my old C64, 1741 floppydrive and an old Samsung "portable" TV in the attick so to speak for, well something like 30 to 35 years. During the the Corona period I dragged this out and tested and unfortunately my C64 didn't work anymore. Got the Light Blue/Blue screen without any text so I guess it could one of the ROMs that are bad. However, I did get hold of another C64 a few years ago that I hadn't tested yet. I found out the old power supplies where untrustworthy so I didn't want to risk anything and it took me a while to get around to order a new.

Well, now I have new powerbrick (ordered from here : https://www.c64psu.com/c64psu/43-1488-commodore-64-c64-psu-power-supply.html) and the other C64 works without any trouble so far. Even the 1741 workes fine. At least 4 of the 5 old floppies (with hrm, "backups") works. I still didn't have any way to get the game over to the C64 but after looking a bit only I ended up with a TapeCartSD solution (cheap, easy to use for non-disk images like prg files).

So today I tested Petaxian on real hardware for the first time.

I may have to make the game a bit harder since I beat this on first try even with the terrible joystic (none of the decent joystic I bought back then lasted very long as far as I remember).

The screen quality of the TV wasn't great when it was new, and has probably not gotten any better in the last 35 years and the antenna output is pretty bad as well. I actually tested with a monitor I have that takes just about anything as input (including from antenna) and the picture quality was actually worse than the one in the CRT. I'll just have to order C64 to SCART plug. Those are pretty cheap.

[desertfish]

Wow amazing!! I have yet to beat the game, but I play mostly with keyboard on the emulator, which isn't ideal for this.

 

Also, is that a D&D character sheet on the table?

Edited Wednesday at 11:59 PM by desertfish

[borgar]

On 5/19/2022 at 1:58 AM, desertfish said:

Wow amazing!! I have yet to beat the game, but I play mostly with keyboard on the emulator, which isn't ideal for this.

 

Also, is that a D&D character sheet on the table?

Keyboard isn't as good as a controller that is true. And I may have played the game a few times more than you for some reason .

And well spotted, it's a D&D sheet. Though this was printed for my son and not myself. I haven't been able to inspire my son to take up computers and programming, but I did manage get him into D&D.