mbessey

4 ms·

1.
by mbessey 1y ago
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 t
2.
by mbessey 1y ago
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 m
3.
by mbessey 1y ago
Yes, it's a cool hack, but doesn't really even approach the same use cases as something like p-code.
4.
by mbessey 1y ago
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.
by mbessey 1y ago
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 s
6.
by mbessey 1y ago
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 reme
7.
by mbessey 1y ago
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 comp
8.
by mbessey 1y ago
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 stil
9.
by mbessey 6y ago
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 o
10.
by mbessey 6y ago
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'
11.
by mbessey 9y ago
Yes, and there are dozens of spam packages registered (and deleted) every day.
12.
by mbessey 9y ago
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.
13.
by mbessey 9y ago
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 (
14.
by mbessey 12y ago
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
15.
by mbessey 12y ago
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 Japan
16.
by mbessey 13y ago
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
17.
by mbessey 13y ago
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.