Prog8 language and compiler topic

[yock1960]

I tried re-compiling one of my programs, one from back in the version 8 days. It uses some @shared declarations for some assembly code. Makes it through compile, but 64tass complains about undefined symbols. Trying to work through this, I discovered that @shared floats seem to work, at least they make it into the vice-mon-list file, but not bytes.

[desertfish]

If you're coming from 8.0 or earlier, you have to make several changes. If you were using inline assembly, perhaps the most important one is that the translation of symbols has been changed.

Read all the details to get from 8.0 to 9.0 here https://github.com/irmen/prog8/blob/v9. ... ading8.rst
And after that, more changes in the various release notes of 9.1 and 9.2 here https://github.com/irmen/prog8/releases

[desertfish]

Prog8 version 9.3 has been released https://github.com/irmen/prog8/releases/tag/v9.3

[yock1960]

Prog8 version 9.3 has been released https://github.com/irmen/prog8/releases/tag/v9.3

What is 1 << 0? Or rather, what should it be? In any case, the result has changed between 9.2.1 and 9.3.

In 9.2.1 (1 << 0) = 1, which I believe is correct.

In 9.3 (1 << 0) = 0.

[desertfish]

Oops, another error slipped into the expression code changes. I'll look into it.

*edit:* fixed in the master branch for the next release.

[desertfish]

Prog8 version 9.4 has been released: https://github.com/irmen/prog8/releases/tag/v9.4

Contains some bugfixes and some small new features (such as the new pet32 compilation target), but also some performance improvements. Most notably the integer word multiplication routine is ~2 times as fast as before.

[desertfish]

prog8 v9.4.1 has been released: https://github.com/irmen/prog8/releases/tag/v9.4.1

It contains a bunch of bugfixes (and some nice new things such as the "sprites" library module) it's advised to upgrade.

[yock1960]

I might have found an odd bug....it's weird! So, I'm creating a calculator program, more or less as a demo for some GUI code that I have ported from another system. I have just implemented a square function...n x n = ?, which works..to a point. After a fair amount of futzing about in the debugger, I originally thought that when a number went into scientific notation, that the assignment of the result to it's variable, failed. Further investigation disproved this...well, partially. It seems to fail for multiplication. I have performed quite a few additions that get into scientific notation...into the e+13 range...since I haven't implemented entering a value as scientific notation yet....I got tired of adding after a while, but it seems that only multiplication is broken somehow. I tested making assignments from multiplications in basic...from the command line: x=9*9:print x...so on and so forth. That works fine. My program simply takes two variables, both floats, multiplies them, assigns the result to another float. That float then becomes the first term of the next operation and with the square function, this first term is assigned to the 2nd term and then another multiplication....

I just noticed 9.4.1...I'll test this!

[yock1960]

I might have found an odd bug....it's weird! So, I'm creating a calculator program, more or less as a demo for some GUI code that I have ported from another system. I have just implemented a square function...n x n = ?, which works..to a point. After a fair amount of futzing about in the debugger, I originally thought that when a number went into scientific notation, that the assignment of the result to it's variable, failed. Further investigation disproved this...well, partially. It seems to fail for multiplication. I have performed quite a few additions that get into scientific notation...into the e+13 range...since I haven't implemented entering a value as scientific notation yet....I got tired of adding after a while, but it seems that only multiplication is broken somehow. I tested making assignments from multiplications in basic...from the command line: x=9*9:print x...so on and so forth. That works fine. My program simply takes two variables, both floats, multiplies them, assigns the result to another float. That float then becomes the first term of the next operation and with the square function, this first term is assigned to the 2nd term and then another multiplication....

I just noticed 9.4.1...I'll test this!

Still broken. Tested with R43 and R44.

[yock1960]

I might have found an odd bug....it's weird! So, I'm creating a calculator program, more or less as a demo for some GUI code that I have ported from another system. I have just implemented a square function...n x n = ?, which works..to a point. After a fair amount of futzing about in the debugger, I originally thought that when a number went into scientific notation, that the assignment of the result to it's variable, failed. Further investigation disproved this...well, partially. It seems to fail for multiplication. I have performed quite a few additions that get into scientific notation...into the e+13 range...since I haven't implemented entering a value as scientific notation yet....I got tired of adding after a while, but it seems that only multiplication is broken somehow. I tested making assignments from multiplications in basic...from the command line: x=9*9:print x...so on and so forth. That works fine. My program simply takes two variables, both floats, multiplies them, assigns the result to another float. That float then becomes the first term of the next operation and with the square function, this first term is assigned to the 2nd term and then another multiplication....

I just noticed 9.4.1...I'll test this!

Still broken. Tested with R43 and R44.

I just wrote a quick program that just does this multiplication and it works fine.

Not sure what gives. Guess I'll figure it out eventually!