| --- Log opened Tue Oct 11 00:00:51 2016 | ||
| _franck__ | https://openiotelceurope2016.sched.org/event/7rsL/open-source-tools-for-fpga-development-marek-vasut-denx-software-engineering?iframe=no&w=i:100;&sidebar=yes&bg=no | 04:27 |
|---|---|---|
| _franck__ | ^ ELCE talk | 04:28 |
| olofk | I should get him to use FuseSoC :) | 04:39 |
| -!- Netsplit *.net <-> *.split quits: Shentino, SMDhome1, LoneTech, Amadiro_, Finde, Hoolootwo, _florent_, parasite | 04:41 | |
| -!- Netsplit over, joins: Shentino | 04:48 | |
| olofk | Is anyone going to ELCE? | 04:53 |
| olofk | oh, it's now | 04:55 |
| wallento | ZipCPU, you there? | 07:33 |
| ZipCPU | Good morning, wallento! | 07:49 |
| wallento | good morning, I have a question regarding your talk | 07:50 |
| wallento | wanted to catch you, but time was running so fast this weekend | 07:50 |
| ZipCPU | Sure, I love questions! | 07:50 |
| wallento | The 32 bits loads and stores only, first striked me a bit of a mood-killer | 07:51 |
| wallento | but then my thoughts diverged from your actual presentation | 07:51 |
| ZipCPU | Go on ... | 07:51 |
| wallento | I was thinking: "Okay, 32 bits accesses only, but you can still map reading uint8_t to a 32 bit aligned load and AND or shift left 24-shift right 24" | 07:52 |
| wallento | but you said there is no uint8_t supported | 07:52 |
| wallento | is that because you cannot do what I was thinking efficiently? | 07:52 |
| ZipCPU | Yeah ... so, here's the problem: The ZipCPU supports 32-bit addressing, where each address # references a word of memory. | 07:53 |
| ZipCPU | While I could create Load/Store instructions with the lower bits of the address, and have the compiler automatically adjust to get a character of interest, | 07:53 |
| ZipCPU | I'd then need a 30 bit address instead of a 32-bit address. | 07:54 |
| ZipCPU | The alternative, would be to move to 34-bit addresses for everything ... but that would require two words of storage. | 07:54 |
| ZipCPU | I should point out ... I may yet be convinced to add the LB, SB, LH, and SH instructions. There's room in the instruction set for them (I'd steal it from the unused FPU instructions ...). I'm really on the fence on this issue. I keep going back and forth. | 07:56 |
| ZipCPU | It would mean a lot of rework with GCC and binutils ... but it's all doable. | 07:56 |
| ZipCPU | I think they'd both be happier with byte-wise access. | 07:57 |
| ZipCPU | I should point out ... the rest of the world uses the 30-bit address solution ... allowing you to address 4GB of memory. | 08:02 |
| ZipCPU | ZipCPU is unusually with its 32-word address solution, allowing access to 16GB of memory, 4bytes at a time. | 08:02 |
| ZipCPU | s/unusually/unique/ | 08:02 |
| wallento | mmh, I am still not sure | 08:05 |
| wallento | actually I am | 08:06 |
| wallento | 30 bit addresses are okay, right | 08:06 |
| wallento | you could still use 32 bit addresses, but use word adressing | 08:06 |
| wallento | and teach the compiler/binutils that an unaligned load is a sequence of instructions | 08:07 |
| wallento | sb of 0x1 is load from 0x0, shift right by eight and mask upper 24 | 08:08 |
| wallento | the thing is, that's exactly what the bus interface does | 08:08 |
| wallento | in other cpus | 08:08 |
| ZipCPU | Yes. If I were to create SB,LB,SH, and LH instructions ... that's exactly what I'd need to do. | 08:09 |
| ZipCPU | I already have something similar in the wb2axip core--it dynamically converts a 32-bit data bus to a 128-bit data bus, in much of the same way. | 08:10 |
| wallento | code density becomes a serious issue than | 08:11 |
| wallento | *then | 08:11 |
| ZipCPU | How so? | 08:13 |
| ZipCPU | Do you mean ... if the CPU needs to issue instructions to shift words around? | 08:14 |
| ZipCPU | I think, if I adjusted the bus for 30+2 bit support, adding the automatic shifts into the hardware would be the least of my worries. | 08:14 |
| ZipCPU | Support would also need to add "instructions" (really just RTL to instruction sequences) for using 8-bit an 16-bit numbers as well. This would probably (primarily) consist of instructions to (un)sign extend 8-bit/16-bit words to 32-bit words. | 08:18 |
| wallento | yeah, I mean that | 08:22 |
| ZipCPU | wallento: If the ZipCPU had 8-bit access, would you be more interested in trying it out? | 11:33 |
| wallento | I am interested in trying it out anyways | 11:34 |
| wallento | as I said I also like the idea of the 32-bit access | 11:35 |
| wallento | but you buy it with a lot of disadvantages I think | 11:35 |
| wallento | given the design complexity, it would be worth comparing both | 11:35 |
| ZipCPU | Thanks! I'll keep it as is then, for now, but let me know how ... experience ... goes, and (please) let me know if you have any troubles. | 11:39 |
| -!- Finde_ is now known as Finde | 11:46 | |
| kc5tja | DEC Alpha was a word-only load/store architecture, and it suffered because of it. Too many programs (at least those written in C) relied on byte or half-word sized units of data. | 11:47 |
| kc5tja | They eventually added sub-word accessors to the instruction set, as I recall. | 11:48 |
| kc5tja | I don't know how they managed addressing using the lower bits though. | 11:48 |
| wallento | things get messy when your write to the word is not exclusive | 12:05 |
| wallento | like two processors using uin8_t in the same word | 12:05 |
| SMDnote | We need to change openrisc isa in orvdx part: at least we need to fix opcodes encoding | 14:12 |
| SMDnote | how should I propose that changes? | 14:12 |
| olofk | SMDnote: Bring it to the mailing list for discussion | 14:50 |
| SMDnote | olofk: could you tell to which mailing list I should write? | 14:53 |
| olofk | SMDnote: https://lists.librecores.org/listinfo/openrisc | 15:00 |
| olofk | or openrisc@lists.librecores.org if you're already registered | 15:00 |
| SMDnote | olofk: thanks | 15:05 |
| SMDnote | olofk: I think I've sent it | 15:34 |
| olofk | SMDnote: Yes you did. I will take a closer look, but I got an awful lot to do so it will have to wait | 15:50 |
| SMDnote | sure | 15:50 |
| --- Log closed Wed Oct 12 00:00:53 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!