NEWS FOR 2022-12-29

[samiam95124]

******************************* NEWS FOR 2022-12-29 ****************************

End of year news!

1. I returned to implementing the framing changes, see "move to pulldown marks"
   in issues. I just don't like the P5 framing method, and I want to make a few
   changes before I code that in pgen. This is technical, but that would be
   pulldown marks, having the called function/procedure do the framing, instead of
   doing that before the function result and parameter list. This just matches what
   happens in the target processors (x86/Arm) much better. Because changing framing
   is major surgery, I wanted the test catalog to be in good shape before I did
   that. As a result, I went through a complete test series and fixed the resulting
   bugs.

2. The PAT and PRT were put into order, run, and the resulting bugs fixed. Self
   compile was run, and partial spew was run (more to do). I will admit the error
   reporting really sucks in many errors, but it always did (P5/P4/P2).

3. Errors now get reported with full text in-line. I got tired of having to look
   them up at the dictionary at the end.

4. I tried using the debugger a few times. It is really beta, and not very
   workable. Apologies for that.

5. I began a project to get the implemented Pascaline extentions into shape.
   this is about halfway complete. See the Pascaline implementation list, which is
   10/10: Pascaline checkoff list #15 in the issues list.
   This involves completing the Pascaline AT or Acceptance
   Test in ./pascaline_tests, and fixing the bugs found.

Other notes:

I got some pushback on not creating a versioned release for P6, and I admit this
needs doing. I will also admit that the main reason is that I don't want people
to characterize P6 as "only an interpreter". It is not.

The other reason is that there are a lot of band-aids on P6 because of it's host
implementation, presently GPC. Besides difficultly to find and set up that
compiler, but also ugly workarounds with it. A really good example of this is
some changes I needed to make to get byte files to work. The declaration:

type bytfil = packed file of byte;

Works, and I/O to it is bytes, but it only works in GPC mode. In standard mode
it does not, apparently because:

type byte = 0..255;

Does not give you a true byte, even in a packed file. ISO 7185 does make
extending it to integer standard, but packing it into a file is valid, and in
fact records and arrays can do that, it works in pint. I think it used to work
in GPC 32 bit, but I can't verify that, since my GPC/Windows32 implementation no
longer functions.

So the above bytfil declare works, BUT ONLY WITH GPC EXTENDED MODE ON! Why?
Because the GPC built-in byte type is magical, and can only be accessed in GPC
extended mode. Thus I had to work around that by declaring a special ibyte so
the two values wouldn't conflict. This is a good example of a workaround I would
like to flush.

Scott Franco
San Jose, CA