2026-09-12 00:47:23 hello. does anybody have the full instruction set of the MuP20? (not the MuP21) 2026-09-12 00:47:48 the only thing I found was a comparison by Jeff Fox to the MuP21, but it's not enough to reconstruct the earlier set, except that SWAP was removed for the MuP21 2026-09-12 01:53:20 oh, hi, sbp! 2026-09-12 01:53:26 nice to see you! how have you been? 2026-09-12 01:53:49 I didn't know there *was* a MuP20. have you tried asking on comp.lang.forth on Usenet? 2026-09-12 01:55:22 veltas: you can fix that particular HCF problem with resistors (cheap, but slows the bus down) or by using multiplexor trees, for example made out of AOI gates, which is basically how everybody's been doing it for 30 years on chip 2026-09-12 01:55:38 lowtechloskop: hi unjust! long tim no see 2026-09-12 01:56:22 hey xentrac! 2026-09-12 01:58:06 hi xentrac. nice to see you too; I've been not too bad, and I hope you likewise! I've been reading pavnotes and your HN comments for months, and actually this question is posed because I'm trying to construct an instance of Veskeno 2026-09-12 01:58:20 I will ask on other Forth forums if nobody has an answer here 2026-09-12 01:58:30 oh, that's great! I'm delighted to hear it 2026-09-12 01:58:46 I've spent most of the week banging on Claude Opus 5 as hard as I could 2026-09-12 01:59:03 I got it to implement the COMFY Forth scheme last night and this morning actually 2026-09-12 01:59:49 I've run out of tokens for the week and now I have 5200 lines of code to review 2026-09-12 02:01:19 ah, excelent. funny how we're working on similarish things. on the other hand, perhaps not too surprising ;) my idea was to take the common subset of the NC4016 and MuP21 as the basis for a Veskeno, scaled to 32 bits of course. but the MuP21 didn't have SWAP. I thought maybe NC4016 /\ MuP20 would let me cheat and simply turn out to be the former + SWAP :D 2026-09-12 02:02:00 *excellent. but due to Jeff Fox's description, I have doubts and expect it would introduce other instructions that I don't necessarily want in there. I've been doing a lot of benchmarking of different designs trying to get it up to Veskeno's performance standards 2026-09-12 02:02:46 which I'm a bit confused about, since in one case the standard is "1 MIPS", but in another place in the document it's "one million multiply-accumulates per second", which is much harder if (as in NC4016 /\ MuP21) you don't have a hardware MUL 2026-09-12 02:03:29 I did some benchmarking of hardware MUL and felt it wasn't worth the effort, but that was based on a C-subset self-compiler, which, well, is naturally not going to require MUL very often. even so, I expect that it would not be necessary for Veskeno 2026-09-12 02:04:58 MuP20 didn't last long. I remember reading that the first version of it didn't work, which lead to Chuck making changes in OK and eventually the MuP21 2026-09-12 02:05:20 and if you give me some prompts, xentrac, I can run them through Opus 5, Fable 5.1, or Astra for you at any thinking level 2026-09-12 02:06:27 crc: yeah, that's why I've had such a hard time finding it. I've scoured old conference proceedings, magazines, the works. I haven't just spent five seconds on Google. I'm really surprised that the set has vanished without a trace. I have found references to the original P20 simulator, and even looked through contemporary software bundles trying to find it 2026-09-12 02:07:16 I necer saw anything really released about it, apart from a port of eforth and some notes in Vol. 14 of More on Forth Engines 2026-09-12 02:07:29 I never found a copy of either though 2026-09-12 02:08:01 darnit. I would be very grateful if you or anyone else ever manages to surface a copy or anything else related 2026-09-12 02:10:58 Chuck's still around. why not email him to see if he has a copy to share? 2026-09-12 02:14:52 bjorkint0sh: I don't have his current email address. I'd probably only email him as a last resort, if all other avenues were exhausted, but it's a good suggestion, thanks 2026-09-12 02:16:25 you should probably talk to him before he dies 2026-09-12 02:16:59 ^ 2026-09-12 02:17:49 I think you should probably have hardware MUL because it increases performance by an order of magnitude and a half for a lot of common tasks 2026-09-12 02:19:02 sbp: want to try http://canonical.org/~kragen/tmp/ringprint-lightswitch-prompt at whatever you think is the awesomest level? Opus 5 gave me a very good reply, ferreting out some key errors of mine, but still half the things it said were wrong 2026-09-12 02:21:40 At least one copy appears to exist in the CHM's collections : https://www.computerhistory.org/collections/catalog/102774576/ 2026-09-12 02:21:46 I thought you might say that, because of the multiply-accumulator comments in the draft, but as I understand it the goal is to have "good enough" performance and then stop, for the sake of ease of implementation. so, I was thinking, perhaps we should establish the performance vs complexity tradeoff 2026-09-12 02:22:38 therefore I implemented two kinds of MUL in Verilog. one is iterative and requires 39 cycles, and the other full parallel and requires 7 cycles. the transistor increase from the baseline was about 6% for the former, and 66% for the latter 2026-09-12 02:23:27 this made me think that the iterative implementation in hardware is a pretty good tradeoff, but of course from the specification point of view you just say "MUL" is allowed, and then I wonder whether that doesn't incur the same problem that you mentioned for Jets. you give something for people to optimise, and they'll try to optimise the heck out of it 2026-09-12 02:26:28 crc: will look into acquiring that, thanks. I'm not in the US 2026-09-12 02:36:40 xentrac: https://gist.githubusercontent.com/sbp/b9200bd8e9d42b07bcdafb086b3b858d/raw/937cc7e3afdb5e26834861e3ccc2bbbce4615876/ringprint-lightswitch-responses.txt - answers from Opus, Fable, and Astra in that order, all on xhigh 2026-09-12 02:37:44 if subscription fees are the problem preventing continued your prompting, let me know if you have a PayPal address and I can send like 200 USD there or whatever 2026-09-12 02:38:27 *your continued. heh 2026-09-12 02:38:37 great typo on a forth channel though ;) 2026-09-12 03:13:35 sbp: thank you very much! 2026-09-12 03:14:42 sbp: DSP, graphics, analog electronic simulation, linear algebra in general, and neural networks are all basically 99% multiply-accumulates, so lots of chips provide 1- or 2-cycle multiply 2026-09-12 03:15:07 even the microcontroller in the Arduino has a 2-cycle multiply, and most FPGAs have dedicated multiplies too 2026-09-12 03:15:43 just downloaded the entire history of this channel and related logs, and found three mentions of the MuP20 in its entire history before today. the only one that bears on the instruction set is a comment by, I assume, Jeff Fox himself: 2026-09-12 03:15:46 2002-06-04 18:06:51 ... The instruction set changed a lot from P20 TO P21 but very little from F21 to c18. 2026-09-12 03:16:27 yeah, I think that's probably Jeff Fox, RIP 2026-09-12 03:16:56 xentrac: fair enough. the Veskeno draft wavers over this, so I am delighted to hear your current thinking on the matter. please either pm me your email address for PayPal or give me it here - it's gone 2am and I'm likely to fall asleep at my computer if I don't go soon :D 2026-09-12 03:16:58 sbp: basically I think leaving out the multiplier completely was the one mistake that doomed GreenArrays 2026-09-12 03:23:34 maybe on a chip like the GA144 it makes sense to not have a multiplier in every F18A computer, but you should have a good number of them on the die if you want the chip to be competitive for the stuff I listed above 2026-09-12 06:35:17 brianx: /j #gaygeeks 2026-09-12 06:35:20 uargh 2026-09-12 06:35:33 remailingi line of text fiail 2026-09-12 08:31:02 I have always wondered what the GA144 is equivalent to in processing power. I wish someone would come up with a non-trivial application and take some measurements 2026-09-12 08:32:35 Then I could compare it to something else and decide when to use it. I'm guessing the fact that no one knows is part of what hurt sales 2026-09-12 13:41:36 ACTION meows 2026-09-12 13:47:15 roar enyc 2026-09-12 15:25:05 enyc: haha 2026-09-12 15:25:49 MrMobius: yeah, it's hard to benchmark it when you can't compile any existing code or synthesize any existing soft core for it 2026-09-12 15:27:53 if we roughly take 144 cores at 1000 MIPS each, divide by 2 for the stack-machine penalty, and divide by 20 for not having a multiplier, it should be roughly equivalent to a dual-core 1.8GHz laptop CPU from about the time it was released 2026-09-12 15:28:19 just, using a thousandth of the power, and, again, unable to run any existing software 2026-09-12 15:28:26 or softcores 2026-09-12 17:10:42 I would be skeptical of it performing anywhere near that but then that's why we need the benchmark 2026-09-12 17:11:12 even if there was an application for it that wasn't well suited to a single core microcontroller it would at least give something to compare to 2026-09-12 19:26:43 1 2026-09-12 19:29:13 I'm curious why you're skeptical 2026-09-12 19:31:00 it seems like either Chuck would have to have been completely lying through his teeth about how the chip performs, along with all the Forth enthusiasts who tried it, or it would have to be able to do at least that 2026-09-12 21:58:02 If he was wrong I'd say he was maybe delusional rather than lying 2026-09-12 22:04:05 xentrac what about Amdahl's law 2026-09-12 22:04:34 Also what about the network between cores and tiny memory available to each core 2026-09-12 22:10:57 A significant part of the chip is taken up by generating a video signal and running the environment 2026-09-12 22:27:44 And what is the bandwidth you can achieve in/out the chip etc 2026-09-12 22:27:47 So much to consider 2026-09-12 22:35:52 Here I am debugging my printer driver (for ZX Spectrum emulator) easily because it's free software so I have the source code, Richard Stallman would be proud 2026-09-12 23:05:13 In this case 'debugging' turned out to be understanding the documentation (i.e. the source code) so I could use the printer because the GUI makes no sense