🇺🇦 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.
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.
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