I have to say, that is just dang *cool*.  I loved reading your page.  You sir, 
are damned impressive! 

Let me know if you get a Mac version working please. :) 


> On Feb 2, 2018, at 3:24 AM, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote:
> Because of this topic drift, I'd like to inform you, that I
> recently added strings to my version of the Stanford Pascal compiler,
> which is a descendent of the Wirth Pascal P4 compiler.
> My string implementation uses two length fields in front of every string,
> the first being the maxlength field, which tells the maximum length that the
> string can hold, and the second one is the actual length, which obviously 
> should
> be less or equal to the maxlength. Both length fields are two bytes, like in 
> PL/1 varchars,
> so a string can by up to 32767 bytes in length. A string variable defined as 
> STRING (20)
> occupies 24 bytes.
> When the string is used in an expression or passed to a function or returned
> from a function, a different format is used (so that is can be passed over 
> the stack).
> A string workarea exists to hold the temporary strings while doing complicated
> string expressions like concatenations combined with string function calls 
> etc.;
> the used area is freed (by resetting pointers) every now and then to prevent
> memory leaks.
> The string API look much like that from IBMs Pascal/VS. I am preparing a 
> document
> which describes all the technical details about strings in New Stanford 
> Pascal.
> Regarding the problems mentioned below (file buffer, terminal read on reset 
> (input)
> before first writeln), Pascal/VS had functions like TERMIN and TERMOUT, which
> modified the file descriptor to handle terminal output correctly. I did the 
> same
> and inserted a "terminal" flag into the Pascal FCB, so I could fix this 
> problem, too
> (in 2016, already).
> The new compiler version (with strings) will be available in the next few 
> days,
> you can get informations here:
> http://bernd-oppolzer.de/job9.htm
> and here:
> https://www.facebook.com/StanfordPascal/
> The compiler runs on MVS (z/OS, too), CMS (generating 370 machine code there),
> and on Windows, Linux, OS/2, MacOS (and probably every other system, that has 
> a C compiler);
> on the non-mainframe systems at the moment using a P-Code interpreter.
> (The string feature is not yet available for the mainframe version,
> because the new P-Codes are not yet understood by the P-Code to 370 
> translator;
> this will probably follow by March 2018).
> Kind regards
> Bernd
> Am 01.02.2018 um 22:22 schrieb Paul Gilmartin:
>> On 2018-02-01, at 08:37:07, Pieter Wiid wrote:
>>> BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal;
>>> they came later with, e.g. UCSD.
>>> Too true -- Wirth's Pascal was useless for any real work. Character arrays 
>>> only.
>>> UCSD Pascal had strings and async block I/O. Coming from the mainframe, I
>>> really liked that.
>> Isn't async block I/O a function of how the runtime library is implemented?
>> A few decades ago, I participated in development and support of a Pascal RTL
>> (and compiler) which had asynchronous BSAM and BPAM I/O, transparent to the
>> application program.
>> Another problem arose from Pascal's file buffer convention.  I judge this a
>> result of Wirth's fixation on the "structured programming" paradigm of its
>> time.  Apparently he wanted to avoid "END=, ERR=" type signal handlers,
>> This seriously impacted interactive programming: the program issued a READ
>> before writing the prompt for it.  This was partly alleviated by "lazy I/O",
>> but the programmer still needed to code in a counterintuitive order.
>> Borland Turbo Pascal did not implement the file buffer, much to the dismay
>> of a colleague with whom I shared a program that relied heavily on that
>> file buffer:
>> "What is this supposed to do?  It doesn't work in Turbo."
>> "I obeyed the IEEE standard.  Turbo doesn't.  Complain to Borland."
>> (But Turbo was pervasive; a de-facto standard.)
>> POSIX shell has a more rational construct, still signal-free in:
>>     while command; ...; read X; do
>>         ...
>>         process record X
>>         ...
>>     done
>> -- gil

Reply via email to