Follow

I'm quickly coming to the opinion that, if you're doing deep-embedded development in anything except assembly language (or some other language with assembly's level of abstraction), you're just doing it wrong. Full fucking stop.

Sigh.

Two weeks and counting debugging this fucking live-lock bug with this UART, and Rust's utter inability to cooperate with me when debugging is just straight up infuriating.

@josias Yes. Very, very, very yes.

Nearly all Forth systems have source code which maps 1:1 with the produced object code. Even those systems which do not have exact 1:1 correspondance, the relationship between the generated assembly language and the original Forth code is usually obvious upon visual inspection.

In either case, Forth code is significantly easier to debug both interactively and in batch.

@vertigo @josias Asking as a Forth noob: How do you debug Forth? Do you run it in an emulator and step through it? Or add asserts and prints?

@csepp @vertigo @josias

i mostly use debug prints, but the ability to drop into an interpreter at any time is also useful.

@csepp @josias This depends heavily on which forth environment you're working with. I cannot give specifics. However with swift-X, you can compile and run individual words and interrogate and altar variables, and so forth, exactly as if it were a host compiled program. So even though you're working on the target, the user interface is exactly the same as if you were programming on the host.

@vertigo Ah, this one: "SwiftX is an interactive development environment (IDE) and cross compiler for developing code to run on microcontrollers and microprocessors."

www.forth.com/product/forth-cr…

So you can have something like a REPL on the desktop machine, but the code is interactively compiled and run on the device you're coding for? Sounds awesome.

@csepp @josias

@vertigo I recall that the architecture of the PDP-11 was such that it made it fairly easy to write directly in machine codes and without assembly language.
12724 123 -> MOV #123,(R4)+

That was because the codes strictly obeyed a very few rules:)

Yeah, I know, it's old way, it's considered almost indecent now😜

@yrabbit Working with Rust would be OK if I had a target environment that fully supported a debug-mode build of the binary. But, since this is a small microcontroller with very limited flash, that is just not possible for our current environment.

I'd argue, based on this, that Rust is excellent for application development, or maybe large-scale kernel development. But, it's not ready for deep embedded work yet. It's just doesn't support debugging under such tight constraints.

@vertigo @yrabbit I thought for embedded profiles the debug information was split into a separate file (and not included in the binary). Otherwise this should be fixable with doc.rust-lang.org/cargo/refere

@wolf480pl If you use a normal debug build, that is indeed the case. However, because we are optimizing for size, a lot of size optimization takes place before generating the final assembly result. As a result, the resulting assembly language listing bears relatively little relationship to the original source code listing.

@vertigo I remember once hunting down a bug in some embedded code I'd written in C. It turned out that the compiler was getting the order of operations wrong (evaluating || before &&). Using parentheses to make it explicit corrected the problem.

@vertigo Yes, I keep looking at Rust as the next thing to move to for bare-metal, but AFAIK, it still has an unstable ABI, meaning both linkage and debugging are still moving targets, and unlike C99, I can't map it to individual instructions in my head, so it remains in my "for the future" pile. On paper, it offers a lot, but I'm still not ready to make the jump.

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. This arcology is for all who wash up upon it's digital shore.