3 ms·

I didn't understand Oxide's goal. You want to build a "computer" specifically designed for server and cloud. But isn't that actually CPU and general hardware

I didn't understand Oxide's goal. You want to build a "computer" specifically designed for server and cloud. But isn't that actually CPU and general hardware design (like ASIC/FPGA/etc)? What does Rust have to do with that? Are you trying to implement Rust's high-level programming language concepts in silicon so the generated assembly would run faster compared to amd64 or M1 or whatever-used-in-servers?

steveklabnik 6y ago
We are (well, will be) selling physical servers, yes. It involves a lot of that sort of work (hardware design). But we are also writing a lot of software, from the firmware up. And it’s all in Rust. My job responsibilities are firmware/os dev stuff, these folks are working on the higher level stuff. I believe they went over the context in their talk, but haven’t watched it since they gave it, so maybe I’m misremembering.
- ducktective 6y ago
  Very interesting! Good luck to you and your team :)
- scoutt 6y ago
  > firmware/os dev stuff Can I ask which IDE do you use for writing code and for debugging? I read your book (which I think is a great starting point), and now I wanted to start playing with Rust, but for embedded (ARM, bare-metal). I have ~20 years of experience writing mostly C for embedded. What I want is something that allows me to inspect memory, view disassembly, stack trace, setting breakpoints, watching expressions. Much like Eclipse + ARM GCC (GDB) + OpenOCD does, or KEIL uVision, or IAR EW, to name a few IDEs. IDEs I found now supporting Rust are more oriented towards desktop/server development and very limited on the debugging side. I cannot rely on println! since it would require semihosting and I don't want to walk that path yet. I need something more low-level to really understand and learn what's going on and how it's achieved. Thanks.
  - steveklabnik 6y ago
    Hey there! I personally am a vim person, though I've moved to VS: Code with the vim plugin rather than stock vim. For debugging, I use GDB and openocd/pyocd, on the command line. (I am also on Windows, which puts me in the minority in the company, but this stuff all works well there too, in case you were wondering.) Semihosting is annoying, but it is really easy to get going in Rust on bare-metal arm. https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihosting/ https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihost... We basically have a build-time config to switch between semihosting and ITM, though we're probably at the point very soon where semihosting will basically never be useful again. Happy to answer more questions if you've got 'em. Our stuff is still closed source but will eventually be open. You may also want to check out https://knurling.ferrous-systems.com/ https://knurling.ferrous-systems.com/ too; we are using some bits of it but not going whole-hog. Similarly with the rest of the Rust open source ecosystem.
    - scoutt 6y ago
      Thank you! OK. I was thinking to assemble a "Press F5 to debug" solution to speed up my learning process. I'm used to command line tools and hacking stuff together too, so I should be fine if that is the current state of the art for debugging (but it would be difficult to convince my coworkers in the future). I wonder if a combination of Eclipse for Rust and OpenOCD plugin is doable. Or perhaps cortex-debug[1] for VS:Code. I have some research to do, to explore the different solutions. And I'm stuck on Windows too, since many of the tools I use require Windows. Thanks again. [1]: https://github.com/marus/cortex-debug https://github.com/marus/cortex-debug
      - steveklabnik 6y ago
        Yeah, I hear you. Rust tries to fit into existing stuff as much as possible, so stuff that works with openocd/gdb should mostly Just Work, but I just haven't tried it. cortex-debug looks cool, I'll have to give it a shot! It does also say in the README: > Initial support for Rust code (most functionality is working; disassembly views and variables view may still have issues) So, that's pretty cool.

steveklabnik 6y ago

We are (well, will be) selling physical servers, yes. It involves a lot of that sort of work (hardware design). But we are also writing a lot of software, from the firmware up. And it’s all in Rust. My job responsibilities are firmware/os dev stuff, these folks are working on the higher level stuff. I believe they went over the context in their talk, but haven’t watched it since they gave it, so maybe I’m misremembering.

ducktective 6y ago
Very interesting! Good luck to you and your team :)
scoutt 6y ago
> firmware/os dev stuff Can I ask which IDE do you use for writing code and for debugging? I read your book (which I think is a great starting point), and now I wanted to start playing with Rust, but for embedded (ARM, bare-metal). I have ~20 years of experience writing mostly C for embedded. What I want is something that allows me to inspect memory, view disassembly, stack trace, setting breakpoints, watching expressions. Much like Eclipse + ARM GCC (GDB) + OpenOCD does, or KEIL uVision, or IAR EW, to name a few IDEs. IDEs I found now supporting Rust are more oriented towards desktop/server development and very limited on the debugging side. I cannot rely on println! since it would require semihosting and I don't want to walk that path yet. I need something more low-level to really understand and learn what's going on and how it's achieved. Thanks.
- steveklabnik 6y ago
  Hey there! I personally am a vim person, though I've moved to VS: Code with the vim plugin rather than stock vim. For debugging, I use GDB and openocd/pyocd, on the command line. (I am also on Windows, which puts me in the minority in the company, but this stuff all works well there too, in case you were wondering.) Semihosting is annoying, but it is really easy to get going in Rust on bare-metal arm. https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihosting/ https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihost... We basically have a build-time config to switch between semihosting and ITM, though we're probably at the point very soon where semihosting will basically never be useful again. Happy to answer more questions if you've got 'em. Our stuff is still closed source but will eventually be open. You may also want to check out https://knurling.ferrous-systems.com/ https://knurling.ferrous-systems.com/ too; we are using some bits of it but not going whole-hog. Similarly with the rest of the Rust open source ecosystem.
  - scoutt 6y ago
    Thank you! OK. I was thinking to assemble a "Press F5 to debug" solution to speed up my learning process. I'm used to command line tools and hacking stuff together too, so I should be fine if that is the current state of the art for debugging (but it would be difficult to convince my coworkers in the future). I wonder if a combination of Eclipse for Rust and OpenOCD plugin is doable. Or perhaps cortex-debug[1] for VS:Code. I have some research to do, to explore the different solutions. And I'm stuck on Windows too, since many of the tools I use require Windows. Thanks again. [1]: https://github.com/marus/cortex-debug https://github.com/marus/cortex-debug
    - steveklabnik 6y ago
      Yeah, I hear you. Rust tries to fit into existing stuff as much as possible, so stuff that works with openocd/gdb should mostly Just Work, but I just haven't tried it. cortex-debug looks cool, I'll have to give it a shot! It does also say in the README: > Initial support for Rust code (most functionality is working; disassembly views and variables view may still have issues) So, that's pretty cool.