2023-06-01 00:13:09 Looks like if the exception is rsp or r12, the only delta is to add a fourth 0x24 byte to the sequence. 2023-06-01 00:13:27 If it's rbp or r13, we add a byte and change some bits as well. 2023-06-01 05:22:13 Yeah sorry I have been inactive recently, was on holiday followed immediately by a dose of looking after my sick wife 2023-06-01 07:32:50 its all good 2023-06-01 07:33:06 https://godbolt.org/ 2023-06-01 08:16:06 Morning monring. 2023-06-01 08:16:46 So, I believe it now works for all reg/reg and reg/reg indirect operations with no offset. I put in words to handle the rsp/rbp exceptions. 2023-06-01 08:17:08 It's still a quite manageable little bit of code. 2023-06-01 08:17:42 If I can get offset support in there, then I'll consider this part done except for testing it. 2023-06-01 08:18:02 Offsets are one byte when that's sufficient, and then they go to four bytes. 2023-06-01 08:19:51 The code sets a variable "bytes" to the number of bytes - so compiling would be "here ! bytes @ allot" 2023-06-01 09:15:42 KipIngram: are you familiar with godbolt? 2023-06-01 09:15:56 compiler explorer, even. 2023-06-01 09:27:21 Yes, "familiar" but not experienced. 2023-06-01 09:43:54 fair enough. 2023-06-01 10:02:11 So, this is tentative, but I think it may handle everything, index operations included: 2023-06-01 10:02:14 https://pastebin.com/JqFbyzi8 2023-06-01 10:02:38 one byte and four byte offsets 2023-06-01 10:03:05 It's a little bit of a maze of logic, but considering the problem at hand that doesn't surprise me a whole lot. 2023-06-01 10:03:43 I have the compile word just hex printing it instead of putting it anywhere. 2023-06-01 10:04:03 So now I just get to test it until I'm blue in the face. 2023-06-01 10:04:57 I think the absolutely key thing that had to be recognized to make this pan out was the way they swap source and destination register fields depending on whether source or dest is the memory reference. 2023-06-01 10:05:36 If I hadn't seen that, I'd just have had to treat op [reg], reg and op reg, [reg] as entirely separate cases, with separate code. 2023-06-01 10:11:14 If any of you guys want to play with this, you'll have to do a little adjustment. Changes the hex numbers from x:ddd to 0xddd, and then there are a couple of conditional returns. You might do something like this: 2023-06-01 10:11:59 : 0=; 0= if r> drop then ; 2023-06-01 10:12:00 etc. 2023-06-01 10:12:33 I also have a 1+! word, but that's pretty easy to write. 2023-06-01 10:14:27 I don't love the . at the front of each machine operation word, but I have words or and xor already, so at least those needed to be differentiated, and once that happened it seemed sensible to change them all. 2023-06-01 10:14:46 I overlooked that at first and had a fun few minutes figuring out why it was suddenly broken. 2023-06-01 10:23:22 Oh, and you'd drop the "rot" just after the two builds> invocations. 2023-06-01 10:23:29 I haven't fixed my builds> does> yet. 2023-06-01 10:39:57 https://imgur.com/a/vruTEwa 2023-06-01 10:40:11 can anyone here tell me why x86 has such a bloody long interrupt latency? 2023-06-01 10:42:13 :-) Not a clue. How long are we talking about? 2023-06-01 10:42:33 And you literally mean the PROCESSOR latency? Not a whole slew of OS hanky panky? 2023-06-01 10:42:49 processor latency 2023-06-01 10:43:19 and it is on the order of hundred if not thousands of cycles or instructions 2023-06-01 10:52:21 but then again I am comparing it with RTX2010 2023-06-01 11:03:25 Yeah, that does seem pretty bad. 2023-06-01 11:03:36 I mean, there's not a whole lot it has to do. 2023-06-01 11:11:54 It uses a separate stack for interrupts, right? So, flip a bit to switch to that, shove the PC and status regs onto the stack and jump to the vector, right? 2023-06-01 11:14:06 not sure, I think it just flips a bit and does the equiv of an call to the interrupt service routine 2023-06-01 11:14:31 Isn't a modern X86 processor hundreds of times faster than an rtx2010? 2023-06-01 11:15:37 probably but I suspect that x86 is still slower to respond 2023-06-01 11:18:43 MrMobius: even more. 2023-06-01 11:19:20 orders of magnitude faster 2023-06-01 11:20:35 the little 8080 that could 2023-06-01 11:20:39 cant say the same about being able to safely execute on space though 2023-06-01 11:21:17 though I heard a rumor intel wants to boot to 64bit and not 16 bit reals 2023-06-01 11:21:24 basically, its faster and can move extremely large amounts of data 2023-06-01 11:21:26 its not a rumour 2023-06-01 11:21:37 https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html 2023-06-01 11:22:12 i'm not sure how long it'll take to happen 2023-06-01 16:46:48 Ok, so this code still has a small glitch. [rbp] works, but [rbp+??] isn't quite right. 2023-06-01 16:46:54 Otherwise, haven't found any problems. 2023-06-01 16:47:12 Fixing it doesn't seem impossibly out of reach, but I don't quite see my way to it yet. 2023-06-01 16:47:43 At the moment I'm not actually detecting the exception until fairly late - I may wind up having to check for it sooner. 2023-06-01 16:48:02 Just this one - indirect rbp with an offset. 2023-06-01 17:02:12 I wish I could think of a good way to exhaustively test this. 2023-06-01 17:10:55 I fixed that issue, I think. 2023-06-01 17:11:17 The problem with [rbp] and [rsp] is that both of them have an extra byte. 2023-06-01 17:11:23 However, they're DIFFERENT extra bytes. 2023-06-01 17:11:43 The [rsp] byte is a 24, and is just extra and above and beyond - if you add an offset, you add more bytes. 2023-06-01 17:11:55 But the extra [bp] byte is a zero and is in fact an IMPLIED OFFSET. 2023-06-01 17:12:10 So if you add an explicit offset to that, you don't lengthen the instruction. 2023-06-01 17:12:25 (unless it's a 4-byte offset, in which case you lengthen by 3). 2023-06-01 17:13:02 So the fix was to check the offset in the rbp special case code, and only add the "extra" byte if we didn't already have an explicit offset. 2023-06-01 17:13:15 I'm back to thinking everything works now. 2023-06-01 17:13:39 There's clearly some unnecessary verbosity here - I need to do some factoring. 2023-06-01 17:14:13 in particular s[i] and d[i] are almost exactly alike; I'm sure I can factor that down. 2023-06-01 17:20:31 Latest: 2023-06-01 17:20:33 https://pastebin.com/3h4Jz5jq 2023-06-01 17:22:13 Not so bad, considering it covers about 15,000 cases. 2023-06-01 17:28:10 https://www.nature.com/articles/d41586-023-01801-8 2023-06-01 17:28:26 Single tile that can cover the infinite plane without ever creating a repeating pattern. 2023-06-01 17:28:48 So there go all of the arguments that "if the universe is infinite, then there has to be another copy of you out there." 2023-06-01 17:28:56 Nope - repetition not required. 2023-06-01 17:43:28 I think I can drop a word perhaps called imm? into the does> part of op; it will check for immediate argument cases and handle them, otherwise return and let the existing code do the job. 2023-06-01 17:44:06 That's an easy test - I'm already counting how many registers have been called out. If it's one, then the "source" argument is an immediate value. 2023-06-01 17:49:06 I'm interested in opinions on handling jumps. 2023-06-01 17:49:47 In particular, should I even have the concept of a "label," or should I go after it the Forth way where the jump and target points use the stack to communicate? 2023-06-01 17:50:57 Labeled jumps don't fit Forth very well for forward jumps - the label wouldn't exist at the time you assembled the jump. 2023-06-01 17:57:58 Ah, mov immediate deviates from all the other operations - the others all follow a nice pattern.