Status of Pascal

[Chuck(G)]

One of the things that I remember about JRT Pascal for the 8080 (it didn't require a Z80) is that it implemented a segmented/virtual memory scheme. You could have data structures and procedures larger than installed RAM, so long as you had disk storage around. That was pretty remakable, given the resources. But, since Pascal pretty much demands a stack-type structure for implementing procedures and local storage, you'll have to do something elaborate as the 8080 makes it difficult to access stack elements. Usually, something like LXI H,offset DAD SP just to get the address of something. Access is by byte only, not words, since the 8080 doesn't have an indirect register load of a word--you've got to do it byte by byte.

K&R C does not have a "string" type, strictly speaking. BASIC/SNOBOL type strings are composite structures. Memory is allocated to them as needed; that includes temporaries and garbage collection. In most implementations, this is accomplished by using a "descriptor" to deliver not only the location of the data and its (current) length. So, in the BASIC sense of a string you can say:

A$ = B$+C$+A$+D$

No such standard structure exists in K&R C, nor does it occur in Wirth's Pascal. There's a good reason for that. Automatic allocation and garbage collection is a process whose time to execution cannot be rigidly specified--and that's an anathema in system-level code. What C calls strings are really pointers to delimited fixed-length character arrays. That's kind of nasty, since basic operations such as strcat have to calculate the length of its operands and run time; the same for strlen. If you've got a descriptor, you just pull the length from it and you're set to go. Of course, it's perfectly possible to implement a descriptor-dynamic allocation mechanism in C if you need it--it's just not a standard part of the language.

 

[Scali]

What C calls strings are really pointers to delimited fixed-length character arrays.

C doesn't call them that though, the type is just 'char *', which is exactly as it says: a pointer to char.
Strings are a semantic concept, at a level above the C language itself. It's a convention introduced by the C standard library.

That's kind of nasty, since basic operations such as strcat have to calculate the length of its operands and run time; the same for strlen. If you've got a descriptor, you just pull the length from it and you're set to go.

Yes, this is a common example to 'prove' that other languages are faster. Eg, Java and C# use Pascal-like strings, where the length is stored with each string in a very simple data structure. This makes operations like string-length or string concatenation much faster than having to scan for the zero-terminator every time.

Of course, it's perfectly possible to implement a descriptor-dynamic allocation mechanism in C if you need it--it's just not a standard part of the language.

In this day and age, it's a moot point though. Most C compilers are actually C++ compilers, and C++ gives you STL, which includes the std::string type, which gives you all that.
Depending on your needs, std::string may perform better or worse than zero-terminated char* (it is not implemented with zero-terminated strings internally, but you can convert to/from zero-terminated strings. The auto-(re-)allocation of strings may harm performance in certain scenarios, and can be unpredictable).

 

[CP/M User]

Yes, this is a common example to 'prove' that other languages are faster. Eg, Java and C# use Pascal-like strings, where the length is stored with each string in a very simple data structure. This makes operations like string-length or string concatenation much faster than having to scan for the zero-terminator every time.

I've actually got a routine in z80 assembly which does this, though it's a bit odd where the string goes, from what it appears, the String Goes based on where HIMEM is set. HIMEM is a reserved word which holds the address when combining BASIC & M/C in memory, to protect the M/C a MEMORY command is used to protect anything using that space. The routine I found takes the lower end of that address and places the string there, the M/C routine also places the address where the string is placed as well as the Length of it. So I should be able to integrate it into my Pascal code, though I don't understand the routine properly and want to try and learn more about it before using it.

 

[Chuck(G)]

In this day and age, it's a moot point though. Most C compilers are actually C++ compilers, and C++ gives you STL, which includes the std::string type, which gives you all that.
Depending on your needs, std::string may perform better or worse than zero-terminated char* (it is not implemented with zero-terminated strings internally, but you can convert to/from zero-terminated strings. The auto-(re-)allocation of strings may harm performance in certain scenarios, and can be unpredictable).

The whole idea of zero-terminated strings of characters is much, much older than C and has the problem that you have to permanently reserve one value for use as a terminator. CDC 6000 systems use 6 bit character/60 bit word representation. Early on, the character set was defined as 63 characters from 01-37 octal, with 00 being reserved as a line terminator. However, the pressure to add another character to the set led to defining 00 as a colon (":"), with 00 being a line terminator only when appearing in the lowest order two or more characters in a word. Of course, this led to problems when multiple colons were involved, or colon was the last character in a line. It was all very messy and lasted well into the 80s with the Cyber 180 line. In the last incarnations of systems using 6-bit codes, certain characters were employed as "escape" characters to allow for more additions to the character set, with colon being one of those escaped characters. It was pretty ugly and I occasionally run across old tapes using both the old and newer schemes.

In general, character-delimited strings are a lousy idea.

 

[commodorejohn]

Eh, they have their upsides and downsides. You've already covered the downsides, so I'll just point out that character-delimited strings are A. simple (as they require no metadata to tell where the end is,) B. slightly more compact (as, again, they require no metadata to tell where the end is, so unless the length token is only one character, the same string is going to be smaller in character-delimited strings) and C. only limited by available memory (as compared to Pascal strings, which are limited by the range of the length token, so unless you include a full-width pointer with every string, your potential size is smaller than available memory.)

Yes, in some ways they're troublesome, but so are Pascal strings, in some ways. As usual in programming, there is no perfect solution...

 

[Chuck(G)]

I don't think the that the upside of character-delimited strings is particularly attractive. Perhaps it works in string literals, but there the compiler already knows the length of the string--and the requirement for a delimiter foils aspects of literal pooling. If you consider Cs primary heritage, the PDP-11, 16-bit string lengths make eminent sense, because the actual string data will start on a word boundary.

But C was intended as a portable assembly language of sorts, so we shouldn't be surprised at the result.

Do any native C++ compilers, complete with STL exist for 8080/Z80 targets? I don't recall any--the only ones that I've seen have been cross-compilers.

 

[CP/M User]

I was looking into the possibility of what Object Orientated languages existed around in the 80s, though I think if anything was written for an 8bit computer, it would have been done on a small scale. ObJect Orientated languages were simply impractical to have for a Microcomputer.
I'm not really qualified to say what cross-compilers are doing when their producing code for their intended 8bit platform, SDCC for example appears to be a C compiler, though it may process something an OOL might do at compile time, the problem is where to draw the line? An 8bit compiler for example and even early versions of Turbo Pascal (1-3), strap on an library in order for your program to run. A modern day form of this would be Visual BASIC which required some Standard Runtime File, otherwise your program won't run. Turbo Pascal 4 introduced Unit files and the compiler from that stage, could begin selecting what code elements your program need, thus resulting in smaller EXE files.

 

[KC9UDX]

For what it's Wirth, they aren't "Pascal strings," they are ANSI strings, and other languages do use them.

I find them useful, and there are times when I'll use them.

If memory serves, originally Pascal specifically did not use ANSI strings, and it was always bad practise to assume that they were.

Whilst S[0] is used a lot, it's better to use Length(S)

 

[commodorejohn]

I was looking into the possibility of what Object Orientated languages existed around in the 80s, though I think if anything was written for an 8bit computer, it would have been done on a small scale. ObJect Orientated languages were simply impractical to have for a Microcomputer.

Considering that Smalltalk-80 was developed on a system that had 128KB of RAM (and supposedly there was even a third-party Z80 Smalltalk, though I've never come across a copy,) I don't think that's a particularly correct assertion. More likely the culprit is the fact that, by the time OOP had gone from being an interesting topic of research to the New Hotness that everybody wanted (the late '80s-mid '90s,) 8-bitters were on their way out.

 

[CP/M User]

Considering that Smalltalk-80 was developed on a system that had 128KB of RAM (and supposedly there was even a third-party Z80 Smalltalk, though I've never come across a copy,) I don't think that's a particularly correct assertion. More likely the culprit is the fact that, by the time OOP had gone from being an interesting topic of research to the New Hotness that everybody wanted (the late '80s-mid '90s,) 8-bitters were on their way out.

Only that I wasn't implicating a lack of memory as being a main reason for very few OO Languages on 8bit computers, though it could be part of the reason.

Various people have written their reasoning why very few 8bit computers have Object Orientated Programs, the main reasoning seems to be extra overhead to produce them.

 

[Chuck(G)]

For what it's Wirth, they aren't "Pascal strings," they are ANSI strings, and other languages do use them.

I think we're mixing apples and oranges here. "Pascal string" -> "The Pascal languages implementation of character strings"; "SNOBOL string" -> "SNOBOL's implementation of strings". "FORTRAN 66 strings"->nonexistent. How the character set is represented is inconsequential; i.e. ANSI/CP1252/USASCII, 5-level Baudot, Unicode, 6-bit external BCD. It's a way of talking about a composite data structure containing, but not limited to, a sequence of characters with a determinate length.

If we can have COBOL and PL/I, complete with preprocessor running on an 8080, I see no reason why an OOP language isn't possible on 8 bit systems. ISTR that when C++ was just germinating, implementation was done mostly through a preprocessor feeding into a C compiler.

 

[Scali]

ISTR that when C++ was just germinating, implementation was done mostly through a preprocessor feeding into a C compiler.

That is correct, the first version of C++ was a preprocessor called "CFRONT". Which, as the name implies, was a frontend for C.
The first version of CFRONT itself is written in C (or rather, there are parts in C++ which they also provided in CFRONT-preprocessed form as C), and you can get the sources on the internet somewhere, I guess, so you might be able to use it to add C++ support to any number of systems with a C compiler available.
I also found something called 'Comeau'. Which seems to be a more modern version of the same thing: a C++ frontend for C.

 

[CP/M User]

Status of Pascal

I trace that fall from grace of Pascal to its early days in the 1970s. Wirth was distributing a Pascal compiler for the CDC 6000/Cyber 70 systems (copies of the source are on the web--I even have one). The thing that sticks out is that there's almost no I/O defined. Just simple readln/writeln to console. Right away, this gives you the impression that it's not a finished product and you lose people right there.

Turbo Pascal has some I/O routines, though someone was pointing out that Turbo Pascal is a whole other Language from Pascal. I'm using Hisoft Pascal 4T, which has 2 Commands for Read/Writing Data, it's not able to have a Constant Array with Data like Turbo Pascal, so using those commands is the next best thing. Hisoft though have tried to produce a Language which complies with Wirth's Pascal, though have made it possible to tap into all the goodies my system has to offer, so I've been able to write routines to handle Loading Files for example, and in a way it's been useful because they have produced a Language which is quite compact, though can make good use of the systems resources.
Does the early Pascal Wirth created make it possible to tap into M/C or is the INLINE statement something which only came around later?

In the 8-bit platforms, I toyed with Frank Borland's Pascal as well as that of JRT and I wasn't impressed with the code generation.

I'm familiar with JRT Pascal, though haven't used it, does it produce 1 pass code generation CP/M based like Turbo Pascal?

I don't mind using 8bit Languages and have to accept that a compiler is going to strap on a whole Library for the program to function, though a cross-compiler language for your PC can obviously select what a program needs, though I can only assume, it's this checking of what it needs, needs more memory to carry out those tasks?

Even Microsoft F77 seemed to do a better job. DRI's PL/I compiler was surprising in that much of the full language was implemented. But eventually, it pretty much came down to C or assembly (or PL/M if you had an Intel system). Various flavors of BASIC were also popular, particularly for business applications.

I wrote one simple demo in CBASIC86 for CP/M-86, but I had to get the timing right so it would run at the same speed on all PCs & the only way I could do that was getting some Assembly into it, which I recall being very frustrating. I haven't had much to do with Fortran though I brought a Fortran77 book once which had an interesting Text Graphical Pattern in it. I tried compiling it for Digital Research's Fortran and it ended up compiling some massive CMD file (for CP/M-86 v1.1), and I unsure if it worked or not, so just stuck with Turbo Pascal.

But it never seemed like Pascal (or Modula-2) ever gained a wide following.

Modula-2 was available & I think Hisoft wrote one, though it's CP/M based, so it's probably only generating CP/M code, though I haven't found any enthusiasts for the language and just presumed people have moved onto Oberon instead.

So you probably haven't gathered that despite my username being CP/M User, I'm using a different compiler (Hisoft Pascal), to write my programs with, because I was finding myself writing more and more system specific stuff with Turbo Pascal, which had to be executed under CP/M. As a result I think the stuff I've written under the other compiler has been accepted and programs can be loaded from Tape or Disk through the systems BASIC. It doesn't mean that I dislike Turbo Pascal or CP/M now, though I felt it would be better to cease frustrating people with System Specific COM files. It just means that I have to use a Compiler which isn't quite up to Specs with Turbo Pascal and have to resort to finding work arounds for programs to work.

But I was wondering if anyone knows of a Pascal Cross-Compiler capable of generating Z80?
I think the most advanced one I've seen is zx-like-pascal, though everything about it is in Russian, it's targeting ZX Spectrum, I'm unsure how easy it is to have it produce code for another system. The other 2 Pascal compilers I'm familiar with have appeared to fizzled out, "Z80 Pascal" hasn't had any development done on it in years & the other Pascal Compiler ceased production due to limited time by the Author.

 

[Chuck(G)]

Does the early Pascal Wirth created make it possible to tap into M/C or is the INLINE statement something which only came around later?

Not as far as I know. The early ETH Pascal versions seem to be little more than learning tools.

I'm familiar with JRT Pascal, though haven't used it, does it produce 1 pass code generation CP/M based like Turbo Pascal?

It's been years since I've played with it. It's one of the bits of code that borks the NEC V20 8080 emulation microcode. I discovered it and it was subsequently mentioned in the NEC MicroNotes. IIRC, each procedure was laid out like this:

procedure-xxxx local variables and stack
procedure: push psw ; entry point
...

I suspect that it's more of a pass-and-a-half affair.

I don't mind using 8bit Languages and have to accept that a compiler is going to strap on a whole Library for the program to function, though a cross-compiler language for your PC can obviously select what a program needs, though I can only assume, it's this checking of what it needs, needs more memory to carry out those tasks?

That's what linkers are for. Although, I suspect that any implementation that uses segmentation probably can just bring in the routines as they are needed.

I wrote one simple demo in CBASIC86 for CP/M-86, but I had to get the timing right so it would run at the same speed on all PCs & the only way I could do that was getting some Assembly into it, which I recall being very frustrating. I haven't had much to do with Fortran though I brought a Fortran77 book once which had an interesting Text Graphical Pattern in it. I tried compiling it for Digital Research's Fortran and it ended up compiling some massive CMD file (for CP/M-86 v1.1), and I unsure if it worked or not, so just stuck with Turbo Pascal.

Well, when there's no timebase of any sort, things like that get pretty difficult. At least one can perhaps sample the vertical retrace for a hint.

Modula-2 was available & I think Hisoft wrote one, though it's CP/M based, so it's probably only generating CP/M code, though I haven't found any enthusiasts for the language and just presumed people have moved onto Oberon instead.

I'm not aware of any 8-bit versions of Modula-3.

As far as other versions of 8-bit Pascal, no--I think as far as HLLs go, C has become dominant. Intel PL/M isn't bad at all, but it's not PL/I and is pretty much limited to the Intel-ish world.

 

[krebizfan]

Scott A Moore is a follower of the Pascal Standard and provides a website which provides all the official drafts of the standard. Note that he provides extensions to handle file handling and other input/output different from but conceptually similar to the UCSD/Blue Dolphin/Turbo Pascal lineage while knocking Turbo for failing to follow the standard. Check out the newsletters there too.

Modula-2 had a great compiler from Logitech. But much like Pascal, Wirth's design decisions made the language a challenge to handle many common problems which hampered developers trying to keep to the standard.

 

[KC9UDX]

I'm confused. Is there another Hisoft Pascal other than HiSpeed Pascal?

 

[CP/M User]

That's what linkers are for. Although, I suspect that any implementation that uses segmentation probably can just bring in the routines as they are needed.

I've only come across Linkers when I written something in Small-C, though it seems to be a bit vague now, from what I recall I compiled my main program which translated it into Assembly & then use the Linker to Link my Source to the Library, and I think the whole Library was attached to the final program.

I'm not aware of any 8-bit versions of Modula-3.

I'm only familiar with a couple of the Modula-2 languages, Borland made a Turbo Modula-2 & Hisoft FTL Modula-2. In one of the manuals it states it needs 128Kb & recommends a RAM Disk would be a worthwhile investment.

As far as other versions of 8-bit Pascal, no--I think as far as HLLs go, C has become dominant. Intel PL/M isn't bad at all, but it's not PL/I and is pretty much limited to the Intel-ish world.

Sure has. I'm familiar with PL/M, though I'm less familiar with the Language, didn't Gary Kildall use it to write CP/M, or is that a Myth?

 

[krebizfan]

I'm confused. Is there another Hisoft Pascal other than HiSpeed Pascal?

HiSoft had an earlier Pascal for ZX Spectrum and Nascom see http://www.worldofspectrum.org/infoseekid.cgi?id=0008255

Then they did HiSpeed for the Amiga and ST.

 

[CP/M User]

I'm confused. Is there another Hisoft Pascal other than HiSpeed Pascal?

I'm not familiar with HiSpeed Pascal, but with Hisoft Pascal (Hisoft being the name of the Software Developer), the version I'm using was initially developed for ZX Spectrum, though Hisoft appeared to have Tweaked it to give the programmer some advantage of the Amstrad inbuilt goodies, this was released though an early distributer AMSOFT & called Hisoft Pascal 4T in 1984. Later Hisoft did another revision, the language would run under CP/M, so I think it was designed to allow a wider audience across CP/M systems and GSX could be used. That particular language is called Hisoft Pascal 80.

 

[Chuck(G)]

ISure has. I'm familiar with PL/M, though I'm less familiar with the Language, didn't Gary Kildall use it to write CP/M, or is that a Myth?

It's true. Over at Gaby's site, I think she has a very early (<1.0) bunch of CP/M source code. Remember that it was DRI who rolled out a PL//I compiler for their ISV program. It was considerably more powerful than PL/M. Not the complete PL/M language, but a good part of it. Not shabby for an 8080-based compiler.