GeorgeTirebiter

https://archive.org/details/Programming_the_Z-80_2nd_Edition... is where I learned about the "W" and "Z" registers -- if you don't know what they do, I won't spoil your fun reading Zaks! See also http://www.z80.info/zip/z80-documented.pdf

The MOS 6502 was introduced at the WESCON tradeshow in September 1975 and sold for $25 quantity 1. They had a transparent vase full of them, 'proving' they did volume -- but those were all chips that failed post-manufacturing testing, except for the very top layer. Still...

I take the previous point about missing MMX / Vector instructions. Presumably, that's a straightforward optimization, when code is vectorizable? That is, yes, it would be nice to have sections on vector instruction use to demonstrate some appropriate algorithms; point taken.

I think, tho, the fundamental reason is: he specs the machine. It does exactly what he says it does. No edge cases, no surprising behavior that LLVM IR or WASM might have; also, I'm sure he spec'd it to make the algorithms he implements elegant or at least more understandable.

I suspect part our views comes from the purity of Mathematics (Knuth) and the actuality of Computer Science. I'm even sympathetic to your view, because then we could verbatim copy Knuth's algos to WASM etc and run them, and we get a twofer: a deeper understanding of the algo AND a deeper understanding of the underlying V-ISA (PTX, BEAM, WASM, LLVM IR, etc).

I think the learning / understanding of the algos Knuth presents partially comes from us Playing Computer, and manually going through the code. It's that pedagogy comes first, I think.

Next time I run into Don, I'll ask him about this. 'cause you're also correct about L1...Ln caches affecting performance drastically.

(And, yes, I had wondered why Don did MMIX he didn't create a "RISC-V" before there was a RISC-V; that is, why didn't he create the Next Great RISC Machine? He said he talked with John Hennessy and Richard Sites. This was in 1990.)

Here's HN on RISC-V vs MMIX: https://news.ycombinator.com/item?id=14635361

MMIX uses register windows to make stack frame pointer offsets unnecessary when referring to PUSHed arguments. Don is trying to make the algorithms understandable and correct, and by hiding some details that are handled efficiently by compilers (keeping track of FP and offsets), it benefits the human reader.

Don's first computer was the IBM 650 https://en.wikipedia.org/wiki/IBM_650?useskin=vector see also http://ed-thelen.org/comp-hist/KnuthIBM650Appreciation.pdf so MIX was a simplified version of the 650 because, well, it's well-defined and simple -- and Don knew a popular IBM machine very well. And there's this, in Vol 1:

This series of books is affectionately dedicated to the Type 650 computer once installed at Case Institute of Technology, in remembrance of many pleasant evenings.

MMIX is for all you youngsters who think RISC is all the rage ;-) and I think he does an admirable job creating a fully-defined machine that does use more modern hardware techniques. The fact that he fully defines his underlying machine is exactly correct, because it lays the foundation for precisely expressing the algorithms, and for giving Time and Space (runtime) estimates.

I believe it's fundamentally incorrect to think of these abstract machines as 'assembly language' but rather, I think, they define a stable foundation onto which accurately described algorithms can be expressed. You're supposed to 'play computer' and follow along -- step by step -- to understand the deep details of the algorithms.

This is exactly correct. Low 10s of kHz is quite functional for machines moving in human space / speed.

If one is trying to do some assembly line (max # of operations per second), the power requirements alone get hard to manage. And then you're managing back EMF, eddy currents, heck, air resistance!

My rule: have dedicated low-level hw provide smooth PID response, mostly on the P term; and have a higher-level control produce the setpoint. Faster response means less need to rely on I or D terms as much (just because delta-T is so relatively small).

Wow, the Python folks do not want to entertain different goals for the language, it would seem. I still remain interested in whether it makes sense to add features to Python anymore, given that LLMs write all the code. Unless, as I said, such features enhance human comprehension (since we have to review the code the LLM produces).

Absolutely serious question: is anybody actually writing code anymore? (Reviewing it, architecting it, sure -- we do that). But writing code? If NOT, then seems to me, what we want in our LLM output is CODE THAT IS TRIVIAL TO UNDERSTAND (I apologize for shouting from the rooftops.)

I'm not sure adding 'features' to Python anymore makes sense - UNLESS those features help humans understand LLM code. Part of the problem is, of course, that LLMs haven't been trained on the latest-and-greatest, so they won't output any of it (even new training events won't capture the latest very much, since there is so little of it relative to what is already out there).

But again -- do new features help HUMANS understand what the LLMs produce? If not, seems to me ... new features merely add complexity for no apparent gain. (Or am I confused about this?) THANKS for any helpful opinions.

Paul Graham? ;-)

If we used it more than just "ok look it works, we'll standardize on this internally" we'd have been happy to buy it, as we all other open source that has a donation option. We were just getting our feet wet, tho, and that's where it seemed burdensome; heck, if it phoned home every time it was used, it would have noticed we only used it about 3 times!

It was written in older version of PySimpleGUI -- it just stopped working! Pretty annoying.

Now, if only the LoC would recognize the brilliance of the Fossil SCM ....

I had heavily used PySimpleGUI in various work projects, and one day, when I had to run some older piece of code I had not run in a while, I get a notice that PySimpleGUI won't work, because was free, but nobody paid, and so, good luck! So I was piping mad, paid the 3-year or whatever the max license fee was, received a code, and THEN I was able to get my stuff to work, like it used to.

LESSON: N E V E R Use code that can "stop working" until you pay ransom. N E V E R.

At this point, it's irrelevant, because the LLMs can replace PySimpleGUI with PyQt etc so --- thanks but no thanks. I did like it because you could throw up something around a CLI and it looked at least presentable. Now, since 2025, nobody codes anymore, so ... seems to me, this PySimpleGUI 6 is just a bit of history.

Excuse my ignorance, but does this functionally mean we can treat this as a 'microkernel' a la minix? I always liked the 'tiny protected subsystem' in Ring 0, then a Ring 1 for Drivers (which are restartable, and dynamically loadable), then one or two rings for User processes (maybe Ring 2 for 'ls' etc and Ring 3 for typical user processes).

I am also curious: What hardware enhancements would benefit 'lightweight, kernel-enforced isolation' ? Do we need memory tags? HW Capability Lists? ?

( I believe we've concentrated far too much in making "damn fast pdp-11s" with our hardware advances, and far less on building Reliable Systems -- even if a few percent of peak possible performance is consumed by extra HW. )

A bit surprised Sussman's and Wisdom's book hasn't yet been mentioned: https://mitpress.mit.edu/9780262028967/structure-and-interpr...

i let v0 = 0.616u + 0.291v - 0.135 let v1 = if 0 > v0 then 0 else v0

is there something 'less good' about:

    let v1  = if v0 < 0 then 0 else v0 

Is Yoda condition somehow better?

Shouldn't we write: Let v1 = max 0 v0

yes, and, fortunately -- even the frogs have enough awareness they actually jump out before they are boiled.

It's possible. I don't know. My tone comes off as support Elon, and I do not, at all. I've seen first-hand almost all of these tactics while I was at <Elon Company>. I'm observing that some people seem to do OK at Elon's companies, and for many years, and never seem to get the boot or be abused in other ways. Therefore, Elon is probably not quite as bad a manager as he is made out to be. This is all I am saying. Since I have firsthand knowledge, I believe my opinion has value. Those that disagree? Show me your Source of Truth. Thank you.

BIG Head.

Karparthy worked for Elon for, what, 5 years? How did he do it, if Elon is Ivan the Terrible?

I have always disliked the := as assignment operator convention. In these declarative languages, assignment is done frequently. There is little cognitive load to using '=' as assignment, although perhaps a bit jarring for math folk.

<- is somewhat better, but, again, for such a common operation, a single character is just more convenient. Sure, we could have editors that turn "=" into := or <- but now we're getting too fancy especially for something pedagogical.

I also don't mind the -> for C pointers; and certainly don't mind the <= >= or even == conventions (although at least today's compilers warn when they see "if (a=b) ...".

Ultimately, humans won't be writing code anymore anyway ( ;-) ?) so maybe the issue is entirely moot.

One other helpful frame: I consider LLMs simply to be very flexible high-level 'language' Compilers. We've moved up the Abstraction Chain ever since we invented FORTRAN and COBOL (and LISP) instead of using assembly language.

We're 'simply' moving up the abstraction hierarchy again. Good!

I want to be in your camp, and am trying hard. But the OP's blog entry should at least give us a moment to "respect the dead". That's all he's asking, I think.

And all that time spent doing leetcode? Yeah, THAT was time Well Spent.... ;-)

Exactly. On a yuuge project, I first identify the Risks. Then, evaluate the risks -- can <ZZ> actually be done? In XX time? For YY dollars? with acceptable bugs on 1st version?

It's sort of the old General Eisenhower quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."

RX-01 DEC / IBM 3740 compatible was 77 tracks, single-sided, 128 bytes per sector and 26 sectors per track. Total 256,256 bytes. FM Modulation. 360 RPM. Disk to drive buffer: 4 µsec per data bit. Track-to-Track Seek: 6 ms. Head Settle Time: 25 ms. Average Access: Approximately 262 ms. 8" diameter diskette

One of these was used to load the microcode into the VAX-11/780 upon boot.

Interesting history, which does seem to be true: In the Beginning, the reliability of floppies was really quite good. Over time, as the mass market developed, however, quality went down as people shaved pennies and fractions of pennies. Storied brands such as Sony ended up being bad sector magnets (well, you know what I mean...).

My big secret for those of us still using floppies (USB floppies are a steal!) --- get Maxell NOS; they're about $3 per diskette now, but I have beat them hard and they keep going. Of course, I also had a batch of poorly-stored floppies that would not even turn (!) from one vendor (cheap, tho...) and they almost ruined one drive.

My rule now is: once a single sector goes kaput, make a new working copy from your backup (you HAVE a backup, right???), mark the bad sector of the failed disk, and put it in the 'BAD' pile. I have not yet had a sector on a Maxell 1.44 diskette go bad. Several SONY diskettes however are in that pile.

Note that the head drags on the surface of a floppy, so you're always losing a little; what that closeness does, tho, is allow phenomenal bits-per-square-inch. The coatings are very good, binders are good, magnetic properties are excellent. And the head widths (both sides, after all) are small. So you get formatted 80 cylinders of 18,432 bytes per cylinder MSDOS-compatible capacity, at that 5 revolutions per second ( 300 RPM, but gosh, RPS is a better unit here...) speed.

The floppy drive is an incredible chunk of engineering. It's unfortunate that Zip 100 and Zip 250 arrived so relatively late in the game.

;-) looks like they are right, taking the slightly longer view! ;-)

Help me understand this: why would anybody buy a Tesla car today, unless it was incredibly well-priced with respect to the competition? Seems to me, yes, this kills Tesla cars.

I looked at a recent football (US) game, and I could not believe the pictures of the grease bombs they were pushing as 'food'. I literally felt ready to gag when I saw some 'chicken nuggets' or whatever was in the fried outer coating.

I want one the size and shape of the HP-200LX. Oh, in that case, please add a 4K color OLED screen and 5G radio. Lenovo stick for mouse.

Correct. 'Segments' are the Proper Unit to think about a bag of bits doing a computation; pages sitting under segments is how VM systems worked to only load the active parts of segments; that's kind of what defined Demand Paging. We have got to get back to the garden here, we need to start valuing security and safety at least as much as raw speed. https://en.wikipedia.org/wiki/Multics?useskin=vector Tagged memory, Capabilities (highly granular), and, yes, segments. Probably needs a marketing refresh (renaming) so as to not be immediately discarded.