| --- Log opened Fri Dec 02 00:00:09 2016 | ||
| shorne_ | Interesting talk about embedded system testing with Fuego | 00:15 |
|---|---|---|
| shorne_ | http://bird.org/fuego/FrontPage | 00:16 |
| shorne_ | oleg-nenashev: Fuego uses jenkins, it might be of interest | 00:16 |
| -!- shorne_ is now known as shorne | 00:16 | |
| shorne | wallento: I actually am getting 2 more signatures today after I gave this talk today | 08:54 |
| wallento | we really get this going! :) | 08:54 |
| shorne | supposedly if I have 3 I can get a kernel.org account | 08:55 |
| olofk_ | shorne: Cool. I forgot where you gave the talk. Do you have a link? | 09:06 |
| shorne | its an embedded linux micro conference | 09:08 |
| shorne | uploaded my slides here, similar what I gave at orconf, but more intro to openrisc | 09:09 |
| shorne | http://elinux.org/Japan_Technical_Jamboree_59 | 09:09 |
| shorne | Many talks were all in Japanese, but it was interesting | 09:09 |
| shorne | one talk was about sony's use of NuttX in its smaller appliances | 09:10 |
| shorne | like audio recorders | 09:10 |
| shorne | But, most of sony's products, like cameras, are linux | 09:12 |
| shorne | it seems everything for the companies there was "arm" though (sony, toshiba, fujitsu,) | 09:13 |
| olofk_ | shorne: Did you remember to speak slowly without any complicated expressions, as stated on the page? :) | 09:24 |
| olofk_ | Cool. I see you did a page on FuseSoC! | 09:26 |
| shorne | olofk_: yes and yes, I thought I I was going to sell people on opencores, the main benefit is inter-operability. Fusesoc is a bit help here. | 17:56 |
| shorne | well librecores (open ip cores) + openrisc platform | 17:57 |
| shorne | and just one of the benefits in inter-opability | 17:57 |
| ZipCPU | Hello! I was wondering if anyone had any statistics on how easy/difficult it was to switch from user to kernel mode as a result of a system call within Linux. | 20:53 |
| ZipCPU | I'm trying to build something similar, and I'm getting disappointed at the complexity of the task. | 20:53 |
| kc5tja | That would depend on the CPU in question, I'd imagine. RISC-V makes this transition nearly instantaneous. | 20:56 |
| kc5tja | (at least, the ISA enables implementations which are very fast.) | 20:57 |
| ZipCPU | Hmm ... I'm struggling to see how that is so. It seems to me that no matter how instantaneous the hardware makes it (and I could be wrong here), you have to pay for it sooner or later. | 20:57 |
| ZipCPU | For example, if the hardware just switches register sets from user to kernel, then on a full context switch you have to save twice as many registers--right? | 20:58 |
| ZipCPU | Further, wouldn't you then need to use some special machine instructions to get access to those shadow/special purpose registers? | 20:58 |
| kc5tja | Well, yes, "nearly" is the qualifier here. You do have to save and restore state. | 20:59 |
| kc5tja | Kernel-mode is, in practice, used to basically emulate a completely separate processor operating in its own address space. | 20:59 |
| ZipCPU | Well, okay, ... so how does RISC-V make this process simpler? | 20:59 |
| kc5tja | There's a CSR (sscratch) which is typically used to point to the current user-mode thread's context area. | 21:01 |
| kc5tja | On entry to the trap, you can save registers into this area by swapping sscratch with a register and using SW/SD instructions. | 21:01 |
| kc5tja | Likewise, when restoring context, you do the reverse. | 21:02 |
| kc5tja | The code sequence is large, but it's much cleaner a design than Intel's Task State Segments. | 21:02 |
| kc5tja | Also, the trap handler doesn't have to save the entire CPU state if it knows it can get away with not doing so. | 21:02 |
| ZipCPU | Is this documented in volume 1 of the RISC-V ISA? | 21:03 |
| kc5tja | In the privilege ISA spec. | 21:03 |
| ZipCPU | So ... not volume 1? | 21:03 |
| kc5tja | Call it volume 2 if you like, sure. | 21:03 |
| ZipCPU | Ok. That's the spec I don't have (yet). | 21:03 |
| kc5tja | https://riscv.org/specifications/privileged-isa/ will have the latest version available. | 21:07 |
| kc5tja | It's not ratified yet, as some things are still being discussed. | 21:08 |
| ZipCPU | Not ratified, and already past version 1.0? Ok ... | 21:08 |
| kc5tja | But after 1.10, it will be decreed that all future revisions must be backward compatible. | 21:08 |
| kc5tja | Yeah, they version things weirdly. 2.0 is their ratification version. | 21:08 |
| ZipCPU | Ok, I'm pulling it up now. CSR you say? Let's see how a search does with that. | 21:10 |
| ZipCPU | "The standard RISC-V ISA sets aside a 12-bit encoding space for up to 4,096 CSRs". Yeah, I knew there was a reason for building the ZipCPU. ;P | 21:11 |
| ZipCPU | Ok, Tbl 2.3 lists sstatus as CSR #0x100. | 21:12 |
| ZipCPU | kc5tja: Did you deal with *all* of these CSRs with kestrel? | 21:13 |
| kc5tja | No. I have only 18 CSRs (and once I switch to a user-mode-only design, the number will drop). | 21:16 |
| kc5tja | CSR instructions which reference unsupported addresses are required to perform an illegal instruction trap. | 21:16 |
| ZipCPU | So, here was the siren call I noticed: It was costing me ~100 instructions for just one part of a trap/syscall, and these instructions are also heavy on memory too. If you assume that the entire trap takes 200 clocks, then what does that mean for a | 21:18 |
| ZipCPU | serial port which has a new value every 800 clocks or so? | 21:18 |
| ZipCPU | read(serial_fd, &ch, 1) would *never* be able to keep up! | 21:19 |
| kc5tja | That's correct. | 21:22 |
| kc5tja | That's why Unix(-like) OSes accept a buffer and a length pair; it gives them the flexibility to busy-wait on serial ports until the required number of bytes are sent or received. | 21:23 |
| kc5tja | Single-character I/O primitives, like what you find on most 8-bit OSes, just can't keep up with that because the days of 300 bd serial links are long since gone. :) | 21:23 |
| kc5tja | IBM mainframes go even further: a system call like read() is translated into a "channel program", a complete set of I/O primitives to be executed by a dedicated I/O coprocessor. | 21:24 |
| ZipCPU | So ... how would a C-library implement a getchar() system call then? By polling to wait for something to read, and then issuing a non-blocking read to fill as much of its buffer as is available? | 21:28 |
| ZipCPU | Hmm ... maybe I should look that one up. | 21:28 |
| kc5tja | Is this a multitasking or single-tasking operating system? | 21:31 |
| kc5tja | If single-tasking, you can just have a system call that busy-waits. | 21:32 |
| kc5tja | If multitasking, it'll be better to suspend the task on a "waiting" list of some kind, and have the serial port's interrupt handler wake the task later. | 21:32 |
| kc5tja | That way, the CPU is free to process other things while the task suspends until a character has arrived. | 21:33 |
| ZipCPU | I've actually got some fairly simple code for a pipe, implemented as a FIFO in memory, that can handle the suspension you are describing. It's nice: I can read/write from interrupt context, and handle the rest | 21:34 |
| ZipCPU | as necessary from a non-interrupt context. | 21:34 |
| * kc5tja implements something similar in the KIA for the PS/2 port. I needed this because the Kestrel-2 does _not_ have interrupts. ;) | 21:34 | |
| kc5tja | (Kestrel-3 does. But I still want that FIFO. Progress!) | 21:35 |
| ZipCPU | :) | 21:36 |
| ZipCPU | And here I was thinking of implementing a printf as a series of putchar statements as each character became available. Imagine the waste if every one of those was an expensive trap! | 21:39 |
| kc5tja | Yep. select() to indicate if a readable channel has data that can be read (and suspend task until this condition is met), then bulk-read what is there with a single read() call. | 21:40 |
| kc5tja | Getting right pissed. I now know that my missing characters from my keyboard is definitely **NOT** hardware induced. | 21:41 |
| ZipCPU | You beat me to it ... I'm still searching the glibc code ... ;) | 21:41 |
| kc5tja | Lag to my cloud server is highly variable, and it's bloody dropping packets. | 21:41 |
| ZipCPU | No wonder I can't find it ... I was searching stdlib, not stdio ... | 21:42 |
| kc5tja | This is, in part, why Unix-type OSes are so shitty at (hard-)real-time applications like user interfaces. | 21:42 |
| --- Log closed Sat Dec 03 00:00:10 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!