IRC channel logs
2026-06-15.log
back to list of logs
<roconnor>yeah once you are at M1, it is normalish writing in assembly. <matrix_bridge><Andrius Štikonas> I didn't even bother to write GAS version for riscv, just went to cc_riscv64.M1 directly <matrix_bridge><Andrius Štikonas> Jeremiah Orians: riscv port tooks us about 2-3 months if i remember correctly? (Of spare time) <matrix_bridge><Jeremiah Orians> Well every step up until M2-Planet in practice was written in a day (for x86, AMD64 and Knight, arm and RISC-V took a couple weeks but Stikonas did an amazing job with it) <roconnor>The conversion of RISC-V immediate values to hex would make me rip my eyes out. <xentrac>I feel like people who have never written assembly or hexadecimal machine code by hand often have an exaggerated idea of how difficult it is <matrix_bridge><Jeremiah Orians> Well that is why each RISC-V step took a couple weeks <matrix_bridge><Jeremiah Orians> But as you move up the chain, it gets easier and faster <matrix_bridge><Jeremiah Orians> The worst part is counting jump displacements and that is the first thing implemented in hex1. In comparison immediates are pretty straightforward (unless the encoding is screwy) <matrix_bridge><Jeremiah Orians> Yeah but its quirky nature did ultimately get word based support into hex2 and M1 (and RISC-V’s M0) which definitely is a solid fix. In retrospect AArch64 and PowerPC would benefit from moved to that format. <xentrac>a friend of mine from Ohio uses needs-washed often, usually with "needs" being the auxiliary verb <matrix_bridge><Jeremiah Orians> Well, I find it slips out when I get tired or distracted. Like Yoda, sometimes I have to go back and fill in the details. <matrix_bridge><Jeremiah Orians> And hex0 is only 229 to 392bytes (or double that if you are counting hex characters) so literally something that could fit in a postcard <matrix_bridge><Jeremiah Orians> I have a printed copy of all the code up to mescc; it is relatively a small stack. (Too small for a proper book, unless I filled in a bunch of details around it) <matrix_bridge><Jeremiah Orians> Possibly but making that look good would take some skill <xentrac>I met Tom Jennings a couple weeks ago. he has the ITA2 Baudot-Murray code tables tattooed on his forearm <matrix_bridge><Jeremiah Orians> Odd that they encoded 27 and 31 the way they did. I would have collapsed them together as a single mode toggle character and added _ and @ <matrix_bridge><Jeremiah Orians> But I am guessing that if you couldn’t assume that the other side was in a known state. That such duplication makes sense (just spam the desired mode a few times before sending the message) <xentrac>yeah, you can't assume the other side is in a known state <xentrac>also note that those two are carefully assigned palindromic bit sequences <matrix_bridge><Jeremiah Orians> But if they opted to do null padding on messages. (Which has the same character in both modes) then you could safely assume say 5 or more nulls indicate a new message and setting the default state to letters mode; that would eliminate that <xentrac>as are null (blank punched paper tape contains nulls) and space; and CR and LF are reversals of each other <xentrac>Jennings deduces that there was some sort of bit order incompatibility <matrix_bridge><Jeremiah Orians> I am surprised that some mechanical machines reverted to letters mode after newline or space characters. But I guess we take for granted how relatively reliable things are these days <matrix_bridge><Jeremiah Orians> I am reminded of a detail of the original Amiga file system, which every block contained its own LBA, its type, pointers for recovery and a 32bit checksum <matrix_bridge><Jeremiah Orians> But if the drive returned the wrong sector, it would detect that. It would also detect if any corruption occurred in the write or read of a sector (which was redundant given that the MFM format that they used had an ECC block after every sector for correcting such errors and would have thrown a hard read error) <xentrac>most cellphone keyboards also revert to letters mode after newline or space characters; it's not just a failure recovery mechanism but also a data compression mechanism <xentrac>it's possible for corruption to happen in the write or read of a sector in between the CPU and the disk controller, in which case the disk format having an ECC block only helps if the ECC computation is done on the CPU rather than the disk controller <matrix_bridge><Jeremiah Orians> Amiga used specialized chips, so no the ECC calculations were done by the disk controller <xentrac>Butler Lampson's "hints for computer system design" from 01983 recommends "Use hints" on page 17; he relates that in the Alto filesystem each disk page has a "label" naming the file and the block number within that file <xentrac>so you could always reconstruct a filesystem directory with all the surviving pages on the disk <xentrac>I think it's common to disregard the possibility that the wrong sector might get overwritten (for example due to a bit error in communicating the sector number to the disk controller), but Gray and Reuter's _Transaction Processing_ spends a fair bit of time on that problem <matrix_bridge><Jeremiah Orians> Makes me think about the Commander X16’s graphics API. You can write the data to the controller and read the critical bits back prior to ordering it to execute on it