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, 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.

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.