3.5.5

An external library that holds a long or double constant can be used again.

• E449 error reading external library file on a valid library. A class file numbers a long or double constant as two entries of its constant pool but stores it once. The library reader counted it as one, so every entry after it was read one off and the reader ran past the end of the pool. Any library whose Java source had a literal such as 1000L (other than 0 and 1, which need no constant) failed to load, and every function in it was then reported as unknown with E429.
• The build directories are lowercase now: release/, debug/, release-arm64/ and release-android-{arm64,armv7,x86_64}/. Nothing else about make changed.

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes, the full CatchRect project and a program using a library with four long constants, which 3.5.4 rejects with E449: every build writes byte-identical class files. The library test was also built and run in the ANPASIDE emulator, together with a bundled library that divides by 1000L.

Full Changelog: 3.5.4...3.5.5

3.5.4

The case statement compiles, and a unit's negative integer constants keep their sign in the modules that use it.

• case … of. The parser used to recognise it only to reject it with E442. It now compiles for integer, char and string selectors. A label is a literal or a named constant, a unit's included, and can be negative, one of a comma-separated list, or a low..high range; an arm may be empty, and an optional else part takes any number of statements up to end. The first matching arm runs and nothing falls through. A label that repeats or overlaps an earlier one is the new error E465 duplicate case label; E442 is gone.
• Inside an arm, an else that follows a ; belongs to the case, not to an if in front of it: in 1: if ok then go; else stop the else is the one of the case. Everywhere else an if behaves as before.
• A negative integer constant in the interface of a unit, such as KEY_UP = -1, was seen as 1 from every other module, with nothing reported: the unit's symbol file (.bsf) got the value without its sign. It is written with the sign now. A .bsf from an older build still holds the wrong value, so compile the unit again.

case key of
  KE_KEY2:          y := y - 1;
  KE_KEY4, KE_KEY6: x := x + key - KE_KEY5;
  0..31:            delay(50);
else
  x := 0;
  y := 0;
end;

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes, the full CatchRect project and two case test programs, one of them with a unit: every build writes byte-identical class files, they carry the required StackMap attributes, and CatchRect comes out the same as with 3.5.3. The case programs were also run on a desktop JVM with bytecode verification on, 144 checks of which arm is taken, and Selftest, which now covers case, was run in the ANPASIDE emulator.

Full Changelog: 3.5.3...3.5.4

3.5.3

A unit that exports an integer constant or an array can be used from other modules again on 64-bit builds.

• In a unit's symbol file (.bsf) an integer constant was written as a long and read back as an int, and the bounds of an array or subrange were written as 4 bytes each and read back as a long. On a 64-bit build those sizes differ, so the first exported constant or array left the reader 4 or 8 bytes off, and every symbol declared after it in the unit came out as garbage: a program using the unit failed with E428 identifier ... is not procedure, function, variable or unit name on the first of the unit's procedures. It affected x86_64 and ARM64, not armeabi-v7a.
• Both are 4 bytes on every build now, so a .bsf is the same file whichever architecture wrote it.

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes and the full CatchRect project: every build's class files are byte-identical to the output of 3.5.2, and they carry the required StackMap attributes. A unit exporting constants, an array type, an array of records and two routines, with a program using all of them, also compiles to identical output on all six.

Full Changelog: 3.5.2...3.5.3

3.5.2

A unit of a few tens of kilobytes no longer takes minutes to compile.

• mem_free and mem_realloc, inherited from upstream MIDletPascal 3.5, found the block they were handed by walking the list of every live allocation from its first entry. Each call cost as much as there were live blocks, so compile time grew far faster than the source: a 34 KB unit took 3.8 s on a desktop and a 51 KB one took 10 s. On a phone that is a build that never finishes, while the same code split over several small units compiled at once.
• Allocated blocks are now also indexed by address. The 34 KB unit compiles in 6 ms and an 85 KB one in 13 ms. The generated class files are unchanged.

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes and the full CatchRect project: every build's class files are byte-identical to the output of 3.5.1, and they carry the required StackMap attributes.

Full Changelog: 3.5.1...3.5.2

3.5.1

Two parser bugs inherited from upstream MIDletPascal 3.5 are fixed:

• A function that assigns result more than once crashed the compiler with a segmentation fault, on every platform. The first result := freed the routine's name; the second one read freed memory.
• On the static ARM64 build, any program that produced a warning compiled to nothing: exit status 0, no M.class, no message. error_count was declared int in the parser but defined short, so the parser read warning_count in the upper half of the value.

The test data now holds Selftest, one program written to use every type, statement, extension and runtime helper class the compiler knows. It compiles in both math modes, and on a device it checks its own results against known answers. It replaces the four canvas demos, which exercised little that CatchRect did not. Writing it is what found both bugs.

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes and the full CatchRect project: every build's class files are byte-identical to the native x86_64 output, and they carry the required StackMap attributes.

Full Changelog: 3.5.0...3.5.1

3.5.0

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21)

The 64-bit Android builds (arm64-v8a and x86_64) were built with NDK r29 and use 16 KB-aligned ELF LOAD segments, so they support devices with both 4 KB and 16 KB page sizes.

All builds were verified by compiling the full CatchRect project. Generated class and symbol files are identical across architectures, and the output contains the required StackMap attributes.