For short strings (probably most of them) - use a byte for the length (at the string/symbol definition site, alongside the offset) (adds 1 byte * symbols, use high bit if necessary to add bytes for longer strings).
You need the offset into the table anyway.
It isn't strictly better, but it isn't strictly worse, and it gives you the option to reuse sub-strings.
Nothing prevents you from using a shared pool of strings that don't have null terminator. It can even be more efficient, since you don't have the null byte to handle at string end. Depending on the maximum string length you want to support, it doesn't even have to take more space.
Complete assembly.
Wouldn't call it trivial, but not super hard either.
I wouldn't dream of doing this without the complete assembly, not worth the hassle.
You run the risk of ruining something, but for me the reasoning was that worst case I'd still have a conputer I can attach to an external monitor.
Replacement itself is mostly removing screws and cables carefully - followed the ifixit guide.
Had a similar issue - some of the display was garbled for more than a year. Had a replacement screen from aliexpress lying around that cost 126$ two and half years ago, got to do the replacement a few weeks ago, as the kid needed a laptop for school.
Turns out the replacement screen resolution was not the same as the original, but it still works fine, took ~1 hour for the replacement.
So for me it did make sense to repair - it costs less than a new laptop, at least
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.
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...
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.
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
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
I'm wondering if the usage of an em-dash in the article (somewhere towards the middle) is self-aware trolling, or just the result of excessive ai use...
> includes both a human and a computer—and “surprisingly,