mbessey

When I get around to analyzing the p-code instruction set, the code-compression aspect will definitely get a mention.

Stack-based vs register-based instruction sets are a very clear size vs speed tradeoff. That's also one reason that the Java VM was designed with a stack architecture, though in that case, it was download time they wanted to minimize.

The whole thing with UCSD having to essentially "give away" the p-System to a separate commercial entity is a sad part of the history, for sure.

I haven't seen a web-based p-System, either, which was a little surprising to me. You can run either the Apple or CP/M versions through emulating the entire computer, though.

That is probably why nobody's felt the need to make a p-System for the web.

Yes, it's a cool hack, but doesn't really even approach the same use cases as something like p-code.

I will definitely check out SunDog, if I can find it. I haven't yet decided whether I'm making a VM for version II or version IV, or both, yet. I want to be able to run code from Apple Pascal directly, so will likely start from II.5.

An interesting piece of trivia about the Apple III version of Apple Pascal that I learned from this discussion is that it apparently puts p-code and data in their own 64k segments, like you were talking about for your 65816 version.

Yes, that exactly. Part of what made Turbo Pascal so fast was that it kept your entire program, and the compiler, in memory.

You had an option from the main menu to "compile" or "run", which included compiling, but NOT saving your edits first. You could save first, but on a floppy-based system, that could take a while.

I want to say that behavior changed in Turbo Pascal version 2, or 3?

Performance of the p-System is definitely an issue on the Apple II, especially in the "OS" interface and editor, which is all interpreted. But running applications built on it wasn't half-bad.

It's also important to remember that to a large extent, Apple Pascal on the Apple II and other late 1970s home computers wasn't competing with sophisticated native-code compiler suites, but with interpreted BASIC and with assembly language.

Pascal was vastly more-productive than writing in Assembler, and much faster in execution than Apple BASIC. It even had reasonable support for integrating assembly routines for places where you really needed the speed.

The p-System was A LOT more usable on the HP Motorola 68k workstations I used it on. Those were more than adequately fast for the sort of software we were writing for them in 1985.

Thanks for the link to cuneiform, I think I read that paper once, long ago. Will definitely check it out.

Surely some of it is just nostalgia for a "simpler" time, but I think there is a legitimate reason to preserve and celebrate these older systems, too.

It's essentially impossible for a single person to build something as complex as a modern PC "from scratch", or indeed to build an operating system that compares to Windows, Linux, or MacOS.

These old microcomputer systems are simple enough for one person or a small team to understand and build, and they are/were capable of doing "useful work", too, and not so overly-abstracted like some "teaching systems" are.

I think that for me, part of the point of digging into something like the p-System is to show some of the brilliant (and stupid) ideas that went into building something as ambitious as a "universal operating system" in the mid-1970s.

I did mention the Turbo Pascal connection briefly, and I'll probably make a more in-depth comparison in a later post on just the IDE.

I used a fairly early version of Turbo Pascal for DOS for several years after High School. I can still remember the absolute terror of realizing you'd pressed "R" without saving first.

I'm not sure I'm really understanding the question, but "faster at most things" is what I'm getting at. Any time you compare two different processor families, there are going to be some benchmarks that look better on one, and some that look better on others.

For Mac applications (which are obviously what Apple cares about in this context), the new processors will be faster than the previous processors.

For tasks which can be accelerated by Apple's custom silicon (video encoding/decoding, object classification), the ARM Macs will be much faster than the Intel Macs.

You are thinking much too conservatively, in terms of performance. I think 50% faster wouldn't even be worth the effort of making the transition.

If we start from the position that the A12Z is, roughly speaking, on par with Intel's most-powerful mobile processors (per CPU core), then work from there:

The first ARM Macs will not be using that processor. Apple have said publicly that the processor cores in Macs will have features that aren't supported by the DTK's processors. That means they're at least equivalent to the A13, but more-likely a generation newer than that, so A14 (or whatever) equivalent. That's probably a 50% boost in and of itself.

The rumor mill says the Mac chips will have 12 cores, instead of 8. Presumably those are 4 more "performance" cores, so that's another 50% boost.

And if they double the TDP, which should be feasible with forced-air cooling, that's another 50%.

So, that's a 237% performance improvement, under some fairly realistic estimates.

Maybe the first portable Macs with the new chips will "only" be twice as fast as the current MacBookPro line, but they might very well be much faster than that.

Yes, and there are dozens of spam packages registered (and deleted) every day.

Yeah, immutability was something that got kind of glossed over in that article (I'm the author). And Functional Programming was a lot less mainstream then. Maybe I should do an update.

I really need to do an update of that article, with C++ std::thread, libDispatch, and some of the other stuff that's come along in the intervening 11 years. I still spend a lot of time tracking down other people's threading bugs (in an entirely-different codebase, these days) though.

Actually, Cyrillic is an interesting case. The Unicode standard does define completely-separate codepoints for the Cyrillic letters, even for the ones that look "just like" letters of the Latin Alphabet. Greek letters that look exactly like Latin letters get the same treatment.

It's difficult to come up with a logical explanation for why European languages that use their own alphabet get their own codepoints, but ideographic languages need to be "unified", even though the actual letters as used in those languages look different.

The "Han unification" was fundamentally a bad idea, and persists for historical reasons. Back when (some) people thought a fixed-width 16-bit character representation would be "enough", it made sense to try to reduce the number of "redundant" code points. Now that Unicode has expanded to a much-larger code space, I would think they'd choose differently.

Unfortunately, that kind of sweeping change is unlikely any time soon.

I respectfully disagree. If Japanese ideograms and Chinese ideograms actually used different code points (i.e. no "Han unification"), then the problem wouldn't exist - the phone could trivially use a Japanese font for Japanese text, and a Chinese font for Chinese text.

Your browser fills in the "current password" when you try to change your password on amazon.com? How'd you manage that? I have my password saved for amazon, and I don't have to type it to log in, but it doesn't get filled in automatically on the "change password" form (because that'd be stupid).

From the article, it sounded like the improvement was more around better retention of photo electrons, rather than enhanced efficiency. That would mean potentially longer useful exposure times due to deeper wells.