| stekern | juliusb_: I've been thinking about the "flag register" we were speaking about, I think it perhaps would be a good idea that that would be a "normal" GPR and not some special register. The same goes for the PC. | 15:24 |
|---|---|---|
| juliusb_ | yeah, i've seen that before, well, you could just make it any GPR, right? | 15:33 |
| juliusb_ | having it as a special register is VERY handy though | 15:33 |
| juliusb_ | although | 15:33 |
| juliusb_ | do you mean you could have a GPR specified as "the flag register" and all compares end up there? | 15:34 |
| stekern | yes, the latter | 16:19 |
| stekern | pin down one reg as flag reg | 16:19 |
| juliusb_ | do you like the idea of having arbitrary regs selectable as the one we use to compare? | 16:40 |
| juliusb_ | i've just done another spin of this spreadsheet btw | 16:40 |
| juliusb_ | will probably post it somewhere | 16:40 |
| juliusb_ | another cool trick I've seen is that, I believe, the 8051 has this thing where part of its equivalent of the SPR space is a local SRAM | 16:41 |
| juliusb_ | so single cycle guaranteed memory | 16:41 |
| juliusb_ | sorta like the QMEM thing they had in the OR1200 | 16:42 |
| juliusb_ | except it's an architectural specification | 16:42 |
| juliusb_ | well, if you _want_ that is | 16:42 |
| juliusb_ | but you could store away a few KB in SPR space for whatever you want | 16:43 |
| juliusb_ | well, hook up a memory to the SPR bus and you're guaranteed no latency, single cycle access to it | 16:43 |
| juliusb_ | but anyway, that's not somethign i'm considering, but as I'm coding the addressable space of the SPRs, it came to mind that there's a _lot_ of address space in the SPRs | 16:44 |
| stekern | "having arbitrary regs selectable..." <-hmm, I'm not sure I understand what you meant by that | 16:47 |
| juliusb_ | like, if you go "sf rA, rB" and you want to set the flags for the comparison between rA and rB | 17:07 |
| juliusb_ | the flags would normally go into the SPR, but if you had a version which put the flags result into an arbitrary register, so "sf, rA, rB, rC" and the flags results go into rC instead of the SPR | 17:08 |
| juliusb_ | here I'm considering the flags reg to have individual results for "testing" registers (negative, zero etc.) and then comparison flags such as equal, gte, lte, lt, gt, gtu, ltu | 17:10 |
| juliusb_ | all sorts of stuff | 17:10 |
| juliusb_ | ideally the most important flags go into 15:0 | 17:10 |
| stekern | yeah, that sounds good | 17:13 |
| juliusb_ | (because on some of the the 16-bit insns, there's only room for 3-bits of flag selection) | 17:13 |
| juliusb_ | so actually, what I have so far is pretty bad\ | 17:14 |
| juliusb_ | not overly RISCy | 17:14 |
| juliusb_ | the implementation won't be small I believe | 17:14 |
| juliusb_ | although, as far as I can tell it won't be the end of the world | 17:14 |
| juliusb_ | code density is the most important thing | 17:14 |
| stekern | you could probably call that sf cmp | 17:14 |
| juliusb_ | yeah or just cmp | 17:15 |
| juliusb_ | will get my new spreadsheet out this arvo anyway | 17:15 |
| stekern | that's what I meant, rename sf -> cmp ;) | 17:16 |
| juliusb_ | i have a little bit of paid employment work todo :P | 17:16 |
| stekern | but I still think I'm more found of a pinned down gpr flag than the option of spr or arbitrary reg though | 17:17 |
| stekern | *fond | 17:17 |
| stekern | but individual flags sounds good | 17:19 |
| juliusb_ | well it's good that you're fond of that, because the instructions you'll use will be smaller :) | 17:37 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!