> Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years.
Maybe it's trivial to compile Rust code but it's not trivial to build a project with dependencies. I'm trying to get my feet wet with an official USB example project from Embassy on my RP2040. It doesn't work in the latest git repo for some unknown reason (might be my fault, probably is, but it's not obvious to me).
I'm assuming it worked at some point, maybe something changed and someone forgot to update something somewhere (there are lots of example projects). So I thought I'd "git bisect" until I find a working version and go from there. Well, I cannot get it to build against anything older than a year ago and that version also isn't working for me. It's dependency and Rust edition hell.
I used to work on LabWindows/CVI an integrated C development environment. It included an "Interactive Execution Window" where you could build programs piecemeal. You added pieces of code, ran them, then appended more code, ran the new pieces, etc. It was as text window so you had more freedom than in a simple REPL.
It integrated with "Function panels". Function panels were our attempt at documenting our library functions. See the second link below. But you could enter values, declare variables, etc and then run the function panel. Behind the scenes, the code is inserted to the interactive window and then run. Results are added back to the function panel.
These also worked while suspended on a breakpoint in your project so available while debugging.
My understanding was that these features were quite popular with customers. They also came it handy internally when we wrote examples and did manual testing.
Yeah, I find this valuable regardless of the programming language, ideally the toolchain should be a mix of interpreter/JIT/AOT, to cherry pick depending on the deployment use case.
Naturally for dynamic languages pure AOT is not really worth it, althought a JIT cache is helpful as alternative.
I used to run long distance, no music, no headphones, no trackers, no watch. Let your mind drift, or focus on the rest of the course. Or go swimming and count laps. Or go bouldering (in doors), pick a route and focus on it.
I’m not sure I fully understand but this seems to be the kind of problem that Ocaml functors solve. You program against an interface (signature) and you supply a concrete implementation (structure) when you want to run it. You can use different implementations in different parts of your application.
So maybe do something similar in Rust by expanding how you import and export modules?
My first computer was their CP1. It was aimed at older children and teens. You programmed it in a custom assembly language. The manual included lots of projects and instructions on how to hook it up to their electronics kits.
Simon Peyton Jones's "The implementation of functional programming languages" has a chapter on the "Efficient compilation of pattern matching" (chapter 5 by Philip Wadler).
Also Xavier Leroy's ZINC paper (https://xavierleroy.org/bibrefs/Leroy-ZINC.html) although I believe that's no longer the implementation used by OCaml since it got replaced by an even more efficient one.
It explains how to minimize the decisions trees you obtain from a match statement, so you gain a ton of efficiency over a naive implementation, especially for large, multi-column matches.
I bought a cheap FPGA board based on Lattice's ice40. There are free OSS tools to write, simulate, and install your Verilog/VHDL design onto the ice40.
It's probably a far cry from what a professional FPGA programmer does with Vivado etc but it might give you an inexpensive idea of the basics and if you want to pursue it.
Right; i already have looked into this (had gotten a FPGA board from Digilent with Vivado and a whole bunch of FPGA books a while ago) but have not done much with it. I generally like to read/learn different subjects for intellectual curiosity before looking at job/business/etc. opportunities using it.
What i was interested to know from the gp's comment is; what would it take today to actually get into this industry; how the current AI tools make it easy (if at all) and what one should concentrate on if one wants to approach Hardware Chip Design as a whole. The C++ SoC modeling articles i listed above were a great help for me to understand where my software skills could be of immediate value here. Since the gp seemed to be knowledgeable in this domain i was curious to know his take on the overall domain.
I think if I spent more than the last 90 minutes on this, I might come up with more detailed and nuanced opinions for you. Irrespective, hopefully this offers some useful thoughts.
However, most of it was already known and i was looking for something more specific/detailed given the OP article.
In the past i had worked on a custom SoC (on the software side) and had often interacted with the hardware designers to understand more of their domain. The first surprise was that most Verilog/RTL guys didn't know anything about software (not even assembly/C!) while of course embedded software guys (like myself) didn't know anything about HDLs. There was (and is) a very hard disconnect which is quite interesting. In the spirit of the OP article, the book i linked to actually shows a path via Vivado HLS for software folks to move into hardware design using their C/C++ programming skills. But i would like to see some hardware designer here validate that approach in the real-world. Especially now that you have powerful AI tools available to help you do stuff faster and easier.
With the rise of demanding AI/ML/Crypto applications, there is now a greater interest in designing new types of custom hardware requiring Hardware/Software Modeling(verification/benchmarking)/Co-Design/Co-Verification etc. They involve designing complete SoCs containing CPU/GPU/FPGAs based on specific designs. Given that hardware design is a universe of its own, not knowing the overall picture i.e. architecture/tools/methodologies/etc. makes it quite daunting for software folks to approach it.
PS: Maybe you can augment/create-new blog post with an actual case study based on your experiences on steps involved going from ideation to tapeout.
Maybe it's trivial to compile Rust code but it's not trivial to build a project with dependencies. I'm trying to get my feet wet with an official USB example project from Embassy on my RP2040. It doesn't work in the latest git repo for some unknown reason (might be my fault, probably is, but it's not obvious to me).
I'm assuming it worked at some point, maybe something changed and someone forgot to update something somewhere (there are lots of example projects). So I thought I'd "git bisect" until I find a working version and go from there. Well, I cannot get it to build against anything older than a year ago and that version also isn't working for me. It's dependency and Rust edition hell.
reply