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.
How do you represent that pool of strings on-disk?
If we concatenate the raw strings together without the null terminator, either all string references will require a length on top of the offset (25% size penalty for a Elf32_Sym), or we'll need a separate descriptor table that stores string offsets and lengths to index into.
If we prepend strings with a length (let's say LEB128), we'll be at best tied with null-terminated strings because we'd have a byte for the length vs. a byte for the terminator. At worst, we'll have a longer string table because we'd need more than one byte to encode a long string length and we would lose the ability to share string suffixes.
Out of all the jank from a.out and COFF that was eliminated with ELF, that representation for the string table was kept (in fact, the only change was mandating a null byte at the beginning to have the offset 0 indicate a null string). It works fine since the 1970s and doesn't cause undue problems, as nothing prevents a parser to spit out std::string_view instead of const char* for the application code.
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.
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
I guess for $126 you mean just display itself? Not complete assembly?
If so this is like an option for like super skilled 1% of 1% of us who repair their devices.
I obviously checked repair videos and just disassembling top part almost impossible without destroying everything except for aluminum cover. Doing it properly on first try is well beyond my skills.
On top of it there is always risk of getting damaged part considering how super fragile it is.
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.
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...
