<oriansj>hmmm. I think I'm having a mandela moment because I remember a TI processor called Swordfish which was the 32bit follow on for the Texas Instruments TMS9900 but looks like I am wrong... <muurkha>hmm, I don't really know what happened to the TMS9900 line <muurkha>WP says, "With no obvious future for the chip, TI turned its attention to special-purpose processors like the Texas Instruments TMS320, introduced in 1983." <oriansj>and the minicomputer page has no 32bit follow-ons either <muurkha>so it's possible Swordfish might have been an internal codename for the TMS320 or MSP430 or one of their DSP chip lines <muurkha>I kind of like the TMS9900 "workspace pointer" terminology for what I was calling a "self pointer" the other day <oriansj>although the inability to cleanly pass arguments in registers does make the TMS9900 line less than ideal for hand written assembly but works quite well for generated code <muurkha>well, "base pointer" is a very generic term; a stack frame pointer is also a base pointer <muurkha>I haven't seen what the TMS9900 assembly language looks like, but I thought you could pass arguments in registers actually somewhat *more* easily than on other architectures <oriansj>well not exactly, you "push" the values into the new register frame and read from the new offsets after changing of the workspace <oriansj>so not as simple as mov r0, 42 and then just using R0 after but not impossibly hard either as you are only dealing with the Branch and Load Workspace Pointer (BLWP) instruction (and all is well as long as you don't need more than 13 arguments) <oriansj>as there was no stack register nor any stack instructions <oriansj>So you effectively had to manually pass the stack prior to any BLWP call and either made sure the stack was reset to its prior state when you did the Return Workspace Pointer (RTWP) instruction <oriansj>or make sure to back populate the new stack state <oriansj>oh and you have to backpopulate the previous workspace because you can't just return your values in registers either as your workspace is going to be gone <muurkha>that sounds easier than the usual dance of saving caller-saved registers into your own stack frame <oriansj>but that is a huge pain so you'll probably just use the Branch and Link (BL) instruction but that only works 1 deep (unless you create your own stack and remember to push) <muurkha>or saving callee-saved registers on entry and restoring them on exit <muurkha>on SPARC you usually deal with the problems you're describing by overlapping the two workspaces by 8 registers <muurkha>(because that's what the hardware does) <oriansj>muurkha: ummm pushr r2; pushr r3; (operations only using r0-r3) popr r3; popr r2 (results are in r0 and r1) is pretty simple to do <oriansj>pushing manually onto the stack and just counting works for arbitrary numbers of arguments and will generally be cleaned up by either doing sp - depth*register_size or just doing matching pops <muurkha>but you can also just move your arguments into fixed memory addresses unless you have recursion <oriansj>hard to get wrong unless your architecture tries to get clever and makes your life harder <oriansj>I like to have recursion and re-entrant code <oriansj>Position-independent code too if it isn't too hard <oriansj>although some architectures fight you very hard if you try to do that <muurkha>but 99% of subroutines don't need to be PIC or re-entrant <muurkha>on RISC-V it's a PITA to use absolute addresses like that, and PIC and re-entrancy are free, but not on a lot of 70s machines <oriansj>x86 you have to fake a function call in order to obtain the return value on stack <oriansj>but thankfully AMD64 fixed that flaw <muurkha>there was an article about Multics Emacs that described more or less how it was implemented and why. it had buffer-local variables, and I think a lot about what it said about them <muurkha>it said that it would have been possible to implement those buffer-local variables by indexing off a current-buffer pointer, and that would have made it faster to switch between buffers, because you only have to update that one pointer <muurkha>on the other hand, that would also mean that reading or writing those variables would require an extra addition to calculate the address, which would make it slower to read and write them <muurkha>since accessing buffer-local variables is a much more frequent operation than switching buffers, the author (van Vleck?) explained that he chose to put the buffer-local variables at fixed locations in memory, swapping them in or out on every change of buffers <muurkha>which is how amd64 or RISC-V context-switches between subroutines, coroutines, or threads; the TMS9900's workspace pointer represents the alternative approach <oriansj>and if one assumes RAM will always be faster than Processors, it would be a superior solution to dedicated registers <oriansj>however that assumption didn't hold past CMOS DRAM in the 1970s <oriansj>and by the 1980s caches provided meaningful performance improvements ***lukedashjr is now known as luke-jr
***janneke_ is now known as janneke
***gio_ is now known as gio
***bandali_ is now known as bandali
<muurkha>oriansj: there's always been a memory hierarchy with faster and slower forms of memory, and bigger memories have always been inherently higher latency <muurkha>a cache provided a meaningful performance improvement on the CDC 6600 in 01964 ***ChanServ sets mode: +o janneke
<oriansj>a 4bit printed CPU which was being made for under 1 cent per <oriansj>it was on the ycombinator this morning but now nothing