Prog8 language and compiler topic

[borgar]

Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input.

Many thanks.

 

[desertfish]

... unfortunately another asm symbol scope issue now cropped up. I'm not done yet

Edited June 12, 2021 by desertfish

[desertfish]

Poll.

I'm contemplating reverting the Cx16 V39 changes that I have already made in Prog8, for the upcoming 7.0 release -- because the actual release of an official v39 emulator+roms is taking way longer than I anticipated.

1. keep v39 support in Prog8 as it is. You're targeting  v39 already and can run it with a custom build of the emulator+roms as they are now on github
2. revert back to v38 support because that is still the official cx16 release    (and put the v39 changes back in once the official cx16 release is there)
3. make it selectable via a command line switch

Which option would you choose and why?

Edited June 23, 2021 by desertfish

[Scott Robison]

I've not looked at your project to know how possible this would be, but are the differences so onerous that you really can't do #3? Or even #4: Have the runtime select v38 or v39 based on the ROM version at runtime?

I know, it's really easy to say "why not" when you have no idea what the code looks like.

[desertfish]

Good questions.  There's no runtime though: prog8 compiles down to machine code in the end, and while doing so it makes various assumptions about the target platform (cpu type, memory mapped i/o registers, and rom routine locations). For example the memory locations of the floating point routines in rom -which prog8 uses for its float types- have changed between v38 and v39 roms and this will make compiled programs crash when run on the other rom version.
So basically, allowing for a compiler switch more or less requires introducing a third target machine definition in the compiler something which is pretty involved and is potentially going to duplicate a lot of code and library files.

Apart from that, on the discord it was correctly pointed out that it would also introduce the expectation of backward compatibility,  which is complexity that I'm not wanting to go for.

Edited June 23, 2021 by desertfish

[Snickers11001001]

11 hours ago, desertfish said:

Which option would you choose and why?

Make it work how YOU want it to work.   Each of your options has some headaches (for you and for users) but since the major changes in R39 (banking, rom routines that live somewhere else) are probably important for your software, bottom line is you have to decide how much dev time you want to spend targeting an emulator version (and maintaining a parallel code-path for it) to service an emulator/rom version that we know will not be what comes out as the X16 hardware or any future official emulator release.   

Its true that there's a bit of a disconnect right now, with the 'docs' all being r39 but the official downloadable emulator release at r38, but I suspect behind the scenes there are goings on that probably represent a good reason there hasn't been an official r39 release as yet.     If you  target r39 then even if they make some tweaks (whether as part of a release or due to feedback when they ship hardware for beta testing) you can adapt and roll with it.   If you target r38, then you know you're developing toward a dead-end and will have to retool for r39 eventually anyway.   

It seems to me that anyone with the chops to use this particular piece of software (which probably doesn't include me at present although I hope to have the time to play with it later this summer) will be able to make or get their hands on an R39 build during the time (which may be shorter or longer, who knows) before an official r39 release.  

    

 

[borgar]

Right now I'm fine with 1. I'm basically not going to require the new functionality in the near future so the new compiler work with the old emulator for me.

[BruceMcF]

The thing about backward compatibility ... it's backward compatibility with a version of the prototype that is not going ahead to production.

I'm not a prog8 user, SO this doesn't count as a user request, but to my mind, either Micheal Steil just has something taking his time right now, and he'll push a new revision when he has time to do the house keeping, or else is occupied with Kernel development, and the next revision will incorporate additional new ROM code. In either case, reverting to the previous revision is making a change that is on a countdown to needing to be changed back.

So I'd ADVISE against it, but that's just advice, it has no standing as a user request.

Edited June 24, 2021 by BruceMcF

[desertfish]

Seems like keeping the V39 (only) looks to be the best way forward, I'm happy with that. And @borgar makes a good point; if you don't actually use the parts that have changed your program still runs fine on v38.  I'll make sure this is clear in the documentation too

Edited June 24, 2021 by desertfish

[desertfish]

Prog8 7.0 has just been released.

https://github.com/irmen/prog8/releases/tag/v7.0

Major changes and improvements since the previous release:

• CommanderX16 target: we now target the upcoming "V39" of the cx16 emulator and roms. Read the info box in the manual for more details https://prog8.readthedocs.io/en/latest/index.html#required-additional-tools
• the struct language feature has been removed. Rewrite any struct-uses as just the separate variables.
• improved random number generators.
• string encoding and string interning bug fixes
• various compiler crashes fixed
• %asminclude fixed (scopelabel argument removed as well)
• repeat loop code gen optimized some more
• fixed various assembly symbol scoping issues
• documentation improvements
• streamlined the grammar definition and improved some parse errors
• fixed warnings in gradle build scripts, updated some libraries and Kotlin runtime version.

[desertfish]

after a long wait, Prog8 7.1 (beta version) has just been released.

https://github.com/irmen/prog8/releases/tag/v7.1-beta

Most of the changes this time are internal to improve code quality and testability.
But several important bugfixes and enhancements have also been made.
One thing to mention now is that the ``%target`` directive has been removed, the compilation target is set on the command line options.

A full list of changes will be published on the 7.1 final release. In the meantime, here is the changes list since 7.0 https://github.com/irmen/prog8/compare/v7.0...master

Edited October 13, 2021 by desertfish

[Ju+Te]

Wow, this looks like a really good programming environment! Much more structured and high-level than pure assembler language - approximately that what I had dreamed of. And, as a Java developer by heart, I also like how it is made.

[desertfish]

Version 7.1 of the Prog8 compiler has just been released https://github.com/irmen/prog8/releases/tag/version7.1

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

Here's a list of the changes:

- removed %target directive because it was too confusing for what little it did. Just use -target command line option.
- non-asmsub subroutines can no longer be inlined because the way this worked was not reliable
- internal code refactoring to improve testability and reliability
- several error/warning message improvements
- added support for secondary alternative emulator to launch, with '-emu2' option (box16 in case of commanderX16)
- fixes for various issues related to different output path
- %asmbinary path related assembler bug fixed
- float[] array initializer bug fixed
- fixed some assembler bugs in swapping values with swap()
- fixed bug in palette.set_color
- fixed bug in optimizer that sometimes removed subroutines that were referenced, causing assembler crash
- some other miscellaneous bugfixes and improvements.

 

[Ju+Te]

How to use different source code files? Is it possible to declare some library code parts as public (visible to the outside) while others remain private (only visible from the library's code)?

[desertfish]

Everything is public in Prog8, there's no concept of private accessibility. You can use scoping to structure your code though (modules, blocks, subroutines).

[desertfish]

Version 7.2 of the Prog8 compiler has just been released https://github.com/irmen/prog8/releases/tag/v7.2

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

 

This is mainly a version with performance optimizations.
Various parts of the code generator now create faster code, and sometimes also smaller code.
Depending on your source code, you can observe pretty significant gains in resulting program size (tens to hundreds of bytes smaller).

Other fixes:

• PETSCII block drawing character mapping was updated to now correctly separate certain box line characters
• Fixed type casting errors related to certain const propagation
• str is now allowed as a parameter type in subroutines (it is passed by reference/address)
• compiler no longer crashes when an input file doesn't exist
• gradle builds now automatically run installDist task after build
• updated to Kotlin 1.5.31

 

Edited November 6, 2021 by desertfish

[borgar]

Very nice. My only currently working project (https://www.commanderx16.com/forum/index.php?/files/file/182-petaxian/) still compiles and run fine though there is no reason to rebuild and upload yet.

I have made the Git project public (https://github.com/cyborgar/Petaxian) in case anyone want to look at a bit larger Prog8 code example compared to the mostly smaller examples coming with the compiler. I have organized code in multiple files/modules. Though there is no code protection this does require explicit references when crossing modules and that helps a lot with visibility.

I have (slowly) started on another clone game (this one is going to copy liberally from Llamasoft's Gridrunner) but I've just gotten started. I'm going to focus on getting it to work on C64 before I'll probably port it to CX16.

[desertfish]

For comparison

Petaxian compiled with prog8 7.0: 19639 bytes
Petaxian compiled with prog8 7.2: 19405 bytes

234 bytes of overhead removed

update: Petaxian compiled with prog8 7.3: 19258 bytes
               another 147 bytes of overhead removed by producing more efficient code

Edited November 14, 2021 by desertfish

[desertfish]

Version 7.3 has just been released https://github.com/irmen/prog8/releases/tag/v7.3

Docs are here as always https://prog8.readthedocs.io/

More improvements in generated code efficiency, resulting in smaller code that runs faster. (see the post above this one for an indication of savings you might see)
Also added a few small new quality of life features.

• fixed operator not priority: it is now higher prio than and/or/xor !
• fixed division of signed bytes by 2
• added new cos and sin builtin functions cosr8 sinr8 cosr16 sinr16, and also their unsigned valued siblings. These make it easier to deal with arcs of degrees 0-359 rather than 0-255 of the existing trig functions.
• added signed versions of the cx16 virtual registers: r0s - r15s including the L and H byte variants of them.
• less temporary variables generated and used
• more optimizations to expression evaluations
• compiler no longer uses cx16 R15 virtual register as tempvar
• unit tests now use KoTest as test framework.

Edited November 14, 2021 by desertfish

[desertfish]

While I was boasting about the reduced code size of the compiled Petaxian game, I now discovered that a bug has crept in in 7.3 that now makes the sound glitch out on the C64 build of Petaxian. I will investigate and fix this soon, hopefully.

Weirdly enough the game still works fine with sound on the X16 build.

 

update: found the bug and fixed it for 7.4, there was a new optimizer added that was too aggressive in removing double-stores

Edited November 18, 2021 by desertfish

[desertfish]

Version 7.4.1 has been released  https://github.com/irmen/prog8/releases/tag/v7.4.1

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

 

Even more improvements in generated code efficiency, resulting in smaller code that runs faster.

• improved code generation.
• optimizer is now smarter about accesses to memory mapped IO that shouldn't be optimized away
• performance improvements in the compiler itself, updated to Kotlin 1.6
• fixed some illegal instructions in the conv module on c64 target
• other bugfixes
• documentation improvements

Edited December 1, 2021 by desertfish
quick fix for broken function call argument count check

[desertfish]

Version 7.5 has been released  https://github.com/irmen/prog8/releases/tag/v7.5

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

Some new features and more optimizations have been added.

• added diskio.load_raw() to load headerless files
• added cx16diskio with load() and load_raw() that are HIRAM bank-aware
• added cx16.getrambank() / getrombank()
• fix grammar problem: \x and \u escape sequences now work properly in character literals
• fix grammar problem: scoped variables such as cx16.r0-r15 are now allowed as loop variable in for loops
• cx16.r0-r15 are now properly considered to be already in zeropage on X16 if you use them as pointers
• allow using ubyte[] as subroutine parameter type
• some other bugfixes and optimizations

Edited December 10, 2021 by desertfish

[yock1960]

Is anyone using this on a Windows machine? I've tried two different systems now, Win10 & Win7, started with Java 11, moved to the open source Java and all I get are can't access jar file errors.  The entire reason that I like working with 'old' 8bit systems is simplicity! 

[borgar]

Sure. I use this on WIndows 7 (old stationary pc) and Windows 10 (laptop). Never had any problems getting this to work.

BTW, I have just set up a few small bat scripts to compile and/or run stuff. This on I use just to build the Petaxian code, I have variants that can take program name as argument, build for C64 instead for XC16 etc.

SET PATH=%PATH%;..
SET jar=..\prog8compiler-7.5-all.jar

IF %computername%==BIFROST (
  SET javap="C:\Program Files\OpenJDK\jdk-11.0.9.1-hotspot\bin\java.exe"
) ELSE (
  SET javap="C:\Program Files\OpenJDK\jdk-11.0.8.10-hotspot\bin\java.exe"
)

%javap% -jar %jar% -srcdirs cx16 -target cx16 petaxian.p8

..\cmdrx16v38\x16emu.exe -joy1 SNES -run -prg petaxian.prg
 

Edited December 12, 2021 by borgar
typo, clarification

[yock1960]

On 12/12/2021 at 4:58 AM, borgar said:

Sure. I use this on WIndows 7 (old stationary pc) and Windows 10 (laptop). Never had any problems getting this to work.

BTW, I have just set up a few small bat scripts to compile and/or run stuff. This on I use just to build the Petaxian code, I have variants that can take program name as argument, build for C64 instead for XC16 etc.

SET PATH=%PATH%;..
SET jar=..\prog8compiler-7.5-all.jar

IF %computername%==BIFROST (
  SET javap="C:\Program Files\OpenJDK\jdk-11.0.9.1-hotspot\bin\java.exe"
) ELSE (
  SET javap="C:\Program Files\OpenJDK\jdk-11.0.8.10-hotspot\bin\java.exe"
)

%javap% -jar %jar% -srcdirs cx16 -target cx16 petaxian.p8

..\cmdrx16v38\x16emu.exe -joy1 SNES -run -prg petaxian.prg
 

Thanks Borgar! I thought about this, but I thought that after 60+ years of computing, we shouldn't have to do this type of thing anymore! But I guess that's just grumpy old me!