🇺🇦 haxadecimal 🚫👑For no particular reason, I am feeling nostalgic for Turbo Pascal.
Daniel Carosone@brouhaha it was cool and all but I always thought it was trying to be UCSD p-System and didn't quite manage it
@uep Having used both quite a bit, the only things "wrong" with Turbo Pascal compared to UCSD Pascal were:
* Not cross-platform - only supported Z80 and 8088/8086
* No separate compilation or "units" - fixed in Turbo Pascal 4.0 (Early UCSD actually didn't have this either.)
* Not cross-platform - only supported Z80 and 8088/8086
* No separate compilation or "units" - fixed in Turbo Pascal 4.0 (Early UCSD actually didn't have this either.)
Resuna
Ken McLeod@resuna @brouhaha @uep If I recall correctly, UCSD Pascal couldn't be used to make a standalone, all-in-one-binary application. There were separate runtime libraries that had to be present.
Turbo Pascal was extremely fast to compile on a (Mac) 68000 CPU, but it produced code which was flaky on the 68020. I've forgotten the details but Turbo Pascal for the Mac didn't last too far into the Mac II era before being discontinued.
Paul_IPv6i remember learning to code in C using lightspeed C on a mac plus
Clifton Royston@_the_cloud @resuna @brouhaha @uep
ICBW, as I only briefly worked on a system using it, but wasn't UCSD Pascal based on a byte-code interpreter runtime? (That was the "p-system" mentioned up-thread.)
Could that be what you're remembering?
@CliftonR @_the_cloud @resuna @uep
Yes, the p-System mostly used bytecode ("p-code"). There were some native compilers later, and some p-System derivatives that used the host operating system rather than forcing the use of their own.
By the late 1980s, the use cases for a bytecode interpreter language had shrunk dramatically. Yet somehow Java brought that back in the late 1990s. I don't think JVM bytecode would have stuck around long, if not for most JVMs going to JIT.
Yes, the p-System mostly used bytecode ("p-code"). There were some native compilers later, and some p-System derivatives that used the host operating system rather than forcing the use of their own.
By the late 1980s, the use cases for a bytecode interpreter language had shrunk dramatically. Yet somehow Java brought that back in the late 1990s. I don't think JVM bytecode would have stuck around long, if not for most JVMs going to JIT.
@brouhaha @CliftonR @_the_cloud @resuna
Yeah, my impressions at the time (and comments here) were less about the bytecode aspect in particular and more about the idea of a complete environment focused on that language and source files and programs. I used it on Apple][, a lot, where you booted into it as a different system entirely. That was where I went to concentrate on learning "proper" programming in 80 columns. I would now say that the narrower scope that let it be complete was a feature, but that's not quite how I thought of it at the time.
Turbo didn't feel like that at all, but because it was an early version of what we now call an IDE on top of a general purpose operating system, it seemed like it was trying to recreate that. By then I had also been using enough other general purpose operating systems that the mismatch was jarring.
stmuk@brouhaha @CliftonR @_the_cloud @resuna @uep oddly Microsoft had some sort of C compiler which output p-code on various platforms and which was used to port their first spreadsheet Multiplan even to systems like the C64 before they gave up on portibility.
@stmuk @CliftonR @_the_cloud @resuna @uep
For a long time I thought that was just something Microsoft used internally, so I was surprised to learn that it was actually a documented and supported part of Visual C++ back then.
For a long time I thought that was just something Microsoft used internally, so I was surprised to learn that it was actually a documented and supported part of Visual C++ back then.
@brouhaha @CliftonR @_the_cloud @resuna @uep Thanks for that! I thought that as well! I'll have to investigate further.
@stmuk @CliftonR @_the_cloud @resuna @uep
Here's the Microsoft pcode details, provided a while back by @fraggle
fraggle (@[email protected])
@[email protected] here's the pcode help file, one of many that I converted into html a few years ago. Appears to have the full byte code specification https://fragglet.github.io/dos-help-files/pcode.hlp/index.html
Poul-Henning Kamp@CliftonR @_the_cloud @resuna @brouhaha @uep
Funny you should say that, I just dropped the UCSD manual into Datamuseum.dk's BitArchive: