Jump to content

Prog8 language and compiler topic


desertfish
 Share

Recommended Posts

  • 3 weeks later...
Posted (edited)

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 by desertfish
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Posted (edited)

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 by desertfish
Link to comment
Share on other sites

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.  

    

 

  • Thanks 1
Link to comment
Share on other sites

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 by BruceMcF
Link to comment
Share on other sites

Posted (edited)

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 by desertfish
Link to comment
Share on other sites

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.
  • Like 2
Link to comment
Share on other sites

  • 3 months later...

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 by desertfish
  • Like 4
Link to comment
Share on other sites

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

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

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.

 

Link to comment
Share on other sites

  • 2 weeks later...

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 by desertfish
  • Like 3
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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 by desertfish
  • Like 2
Link to comment
Share on other sites

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 by desertfish
  • Like 1
Link to comment
Share on other sites

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 by desertfish
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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 by desertfish
quick fix for broken function call argument count check
  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use