That's if you parse the into a DOM and work on that. If you use SAX parsing, it makes it much better regarding the memory footprint.
But of course, working with SAX parsing is yet another, very different, bag of snakes.
I still hope that json parsing had the same support for stream processing as XML (I know that there are existing solutions for that, but it's much less common than in the XML world)
Some minor nitpicks, but hey, we're counting registers, it's already quite nitpicky :)
Add far as I van remember, you can't access the high/low 8 bits of si, di, sp. ip isn't accessible directly at all.
The ancestry of x86 can actually be traced back to 8 bit cpus - the high/low bits of registers are remenants of an even older arch - but I'm not sure about that from the top of my head.
I think most of the "weird" choices mentioned there boil down to limitations that seem absurd right now, but were real constraints - x87 stack can probably traced back to exposing minimal interface to the host processor - 1 register instead of 8 can save quite a few data line - although a multiplexer can probably solve this - so just a wild guess.
MMX probably reused the register file of x87 to save die space.
The low 8 bits of SI, DI, BP and SP weren't accessible before, but now they are in 64-bit mode.
The earliest ancestor of x86 was the CPU of the Datapoint 2200 terminal, implemented originally as a board of TTL logic chips and then by Intel in a single chip (the 8008). On that architecture, there was only a single addressing mode for memory: it used two 8-bit registers "H" and "L" to provide the high and low byte of the address to be accessed.
Next came the 8080, which provided some more convenient memory access instructions, but the HL register pair was still important for all the old instructions that took up most of the opcode space. And the 8086 was designed to be somewhat compatible with the 8080, allowing automatic translation of 8080 assembly code.
16-bit x86 didn't yet allow all GPRs to be used for addressing, only BX or BP as "base", and SI/DI as "index" (no scaling either). BP, SI and DI were 16-bit registers with no equivalent on the 8080, but BX took the place of the HL register pair, that's why it can be accessed as high and low byte.
Also the low 8 bits of the x86 flag register (Sign,Zero,always 0,AuxCarry,always 0,Parity,always 1,Carry) are exactly identical to those of the 8080 - that's why those reserved bits are there, and why the LAHF and SAHF instructions exist. The 8080 "PUSH PSW" (Z80 "PUSH AF") instruction pushed the A register and flags to the stack, so LAHF + PUSH AX emulates that (although the byte order is swapped, with flags in the high byte whereas it's the low byte on the 8080).
Fun fact, that obviously you already know but may be interesting to others.
In the encoding the registers are ordered AX, CX, DX, BX to match the order of the 8080 registers AF, BC (which the Z80 uses as count register for the DJNZ instruction, similar to x86 LOOP), DE and HL (which like BX could be used to address memory).
It was pretty clear towards the middle of the piece that an ai was involved writing this piece, which was unfortunate, since it distracted me so much from the subject that I couldn't complete reading it...
I think the article could be better and get the point across with half the length and without the second half of it being full of ai generated list of advantages, or using that space to give some more technical information
> Find the (minimal) AI prompt that lead to the generation of this article: [...]
The minimal AI prompt that likely led to the generation of this article could be:
"Write a technical blog post comparing JPEG XL and AVIF image formats, focusing on how JPEG XL's bit-depth-agnostic float-based encoding is superior to AVIF's integer-based approach, with emphasis on perceptual quality, HDR handling, and workflow simplicity."
This prompt captures the core elements:
- Technical comparison between two image formats
- Focus on JPEG XL's unique "ignoring bit depth" design
- Emphasis on perceptual vs. numerical quality
- Discussion of HDR and workflow benefits
- Tone and structure matching the published article
The prompt would have guided the AI to produce content that:
1. Explains the technical difference in encoding approaches
2. Demonstrates why JPEG XL's method is better
3. Provides real-world implications for users
4. Maintains the author's voice and technical depth
5. Follows the article's structure and emphasis on "perceptual intent" over bit precision
This is so meta, we're using AI to generate feedback loops between a prompt, the AI generated content, using AI to recreate the prompt used to generate the content, etc. Spiraling to unreadable slop - unreadable to real humans anyway.
Soon enough the AI will invent a format for communicating with instances of itself or other AIs so that they can convey information that a client AI can translate back to the user's personal consumption preferences. Who needs compression or image optimization when you can reduce a website to a few kB of prompts which an AI engine can take to generate the full content, images, videos, etc?
> Write a short article explaining that JPEG XL's genius is its bit-depth-agnostic design, which converts all image data into a perceptually-based floating-point format (XYB) to optimize compression for what the human eye actually sees. In contrast, AVIF is locked into its video-codec legacy, forcing it to use rigid, integer-based bit-depth modes that optimize for numerical precision rather than true perceptual quality.
What makes you think it is AI generated? Perhaps it's just the Dunning-Kruger effect in an area I'm not especially knowledgable in, but this article strikes me as having more technical depth and narrative cohesion than AI is generally capable of.
It mostly rehashes the point of using float instead of integer representation, and uses different headers (radical solution, why this matters, secret weapon, philosophy, the bottom line) for streching what could be said in a few sentences into a few pages.
The reason AI loves this format is that it was a popular format before generative AI came along. It's the format of clickbaity "smart" articles, think Slate magazine etc.
But because it's for a subject the HN audience is interested in, it actually gets upvotes unlike those sites, so a lot of people reading these get reintroduced to the format.
Tenish years ago we had slop / listicles already and thankfully our curated internet filters helped us avoid them (but the older generation who came across them through Facebook and the like). But now they're back, and thanks to AI they don't need people who actually know what they're talking about to write articles aimed at e.g. the HN audience (because the people who know what they're talking about refuse to write slop... I hope)
Formatting and headers aside, there are lots of local rhetorical flourishes and patterns that are fairly distinctive and appear at a far higher rate in AI writing than in most writing that isn't low-quality listicle copy artificially trying to hold your attention long enough that you'll accidentally click on one of the three auto-playing videos when you move your pointer to dismiss the newsletter pop-up.
Here's something you know. It's actually neither adjective 1 nor adjective 2—in fact, completely mundane realization! Let that sink in—restatement of realization. Restatement. Of. Realization. The Key Advantages: five-element bulleted list with pithy bolded headings followed by exactly zero new information. Newline. As a surprise, mild, ultimately pointless counterpoint designed to artificially strengthen the argument! But here's the paradox—okay, I can't do this anymore. You get the picture.
Inside JPEG XL’s lossy encoder, all image data becomes floating-point numbers between 0.0 and 1.0. Not integers. Not 8-bit values from 0-255. Just fractions of full intensity.
Everything after the first "Not" is superfluous and fairly distinctively so.
No switching between 8-bit mode and 10-bit mode.
No worrying whether quantization tables are optimized for the right bit precision.
No cascading encoding decisions based on integer sample depth.
The codec doesn’t care about your display’s technical specs. It just needs to know: "what brightness level does white represent?" Everything scales from there.
Same general pattern.
JPEG XL not worrying about bit depth isn’t an oversight *or* simplification. It’s liberation from decades of accumulated cruft where we confused digital precision with perceptual quality.
It's hard to describe the pattern here in words, but the whole thing is sort of a single stimulus for me. At the very least, notice again the repetition of the thing being argued against, giving it different names and attributes for no good semantic reason, followed by another pithy restatement of the thesis.
By ignoring bit depth, JPEG XL’s float-based encoding embraces a profound truth: pixels aren’t just numbers; they’re perceptions.
This kind of upbeat, pithy, quotable punchline really is something frontier LLMs love to generate, as is the particular form of the statement. You can also see the latter in forms like "The conflict is no longer political—it's existential."
Why This Matters
I know I said I wouldn't comment on little tics and formatting and other such smoking guns, but if I never have to see this godforsaken sequence of characters again…
It's more than that. They have an unlimited license to arm designs, and can change them as they see fit, since they were an early investors (or something along those lines). Other manufacturers can't get these terms, or if they can, it will be prohibtly expensive
The thing about Apple having a “special license” due to being a partial founder of Arm is an urban legend. They have an architectural license, just like several other companies making custom Arm CPUs do.
It is very unlikely Apple uses anything from ARM’s core designs, since that would require paying an additional license fee and Apple was able to design superior cores using its architectural license.
But of course, working with SAX parsing is yet another, very different, bag of snakes.
I still hope that json parsing had the same support for stream processing as XML (I know that there are existing solutions for that, but it's much less common than in the XML world)