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. :) -Paul > 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 >>
