i_don_t_know

IIRC you have to probe every page of the stack on Windows. You cannot just subtract a value from ESP/RSP. If you don't probe every page in order, you get a page fault or some other exception (I don't remember which one).

Hard real-time control systems is one application.

Iirc, the interpreter recognizes common idioms (sequences of 2-4 operations) and has optimized fused implementations for those idioms that avoid intermediate results.

It can also avoid creating intermediate results for quite a few operations, because for example reverse, transpose, etc only change how the arrays are traversed (order in which elements are accessed). You can reuse the original data and change the indexing information. That’s known as beating and dragging.

Here’s some helpful background information on the project: https://news.ycombinator.com/item?id=47872891

In particular, it has diagrams of the data structures and how the algorithm operates on them.

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.

Thank you!

Sorry, I couldn't find a news report in English. Everything I found was in German.

It's a remake of the Sinclair ZX Spectrum home computer from the 80s, in white.

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.

https://www.ni.com/docs/de-DE/bundle/labwindows-cvi/page/cvi...

https://www.ni.com/docs/de-DE/bundle/labwindows-cvi/page/cvi...

https://irkr.fei.tuke.sk/PPpET/_materialy/CVI/Quick_manual.p...

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?

The Haskell language report precisely defines how layout determines structure: https://www.haskell.org/onlinereport/haskell2010/haskellch10...

Any language that uses layout to determine structure should have a similarly precise definition.

I loved my Kosmos electronics kits. My mom threw out the kits eventually but I still have the manuals.

https://patric-sokoll.de/SonstigeSammlungen/Kosmos%20E200/Ha...

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.

http://www.8bit-homecomputermuseum.at/computer/kosmos_comput...

http://www.8bit-homecomputermuseum.at/computer/pictures/kosm...

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).

https://simon.peytonjones.org/assets/pdfs/slpj-book-1987-2up...

Thanks! That was actually really good. His performance matches the emotions underlying the song.

Something all the covers of Behind Blue Eyes by The Who seem to miss is the slowly rising anger and frustration.

When I became interested in FPGAs recently, I read this book https://nostarch.com/gettingstartedwithfpgas

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.

Chapter 9 and section 10.7 of this book show some interesting (and to me unexpected) uses of effects in Ocaml and how they compare to implementations based on monads:

https://lukstafi.github.io/curious-ocaml/new_book.html

The dscheck model-checker is another interesting application of effects: https://github.com/ocaml-multicore/dscheck

mdx[1] is another variation on this, also in the Ocaml ecosystem. It’s Ocaml’s version of documentation tests as in Elixir and Rust.

But it’s not limited to that. You can write tests in markdown files independently from your documentation. Use “dune test” to run the tests and review failures with “git diff”. Accept the changes if they are correct (changed behavior) with “dune promote”. Very nice workflow.

[1] https://github.com/realworldocaml/mdx

I'm seconding the recommendation to look at Rodnay Zack's books. For example, I really enjoyed Advanced 6502 Programming. It's a project-based tutorial for a custom 6502 machine. The design and schematics are in the book.

https://archive.org/details/Advanced_6502_Programming/mode/2...

Well I am talking about before a military conflict erupts. I’m talking about what is in the interest of the people, when they are looking at a potential military conflict.

When you’re looking at a potential military conflict, you’re looking at a hostile foreign government that’s openly threatening you. What reasons do you have to believe that they will be friendly and that life will go on as usual after you have surrendered?

The foreign government cares about your land, resources, industry, strategic location, etc. They do not care about you, the people. Otherwise they would encourage you to move to them.

In the case of Ukraine, being peacefully “relocated” to Russia seems much better than what is happening now.

Would it be better though? The Ukrainian government was/is far from perfect. But it’s the government they chose, it’s not an authoritarian one (it tried to be which led to the Maidan protests). They chose to be an independent country and in control of their own destiny. They don’t want to subject themselves to an authoritarian foreign government and they consider that to be in their best interest.

I’m not sure the people in Eastern Ukraine who have been “relocated” to Russia agree with your idea of “nothing changes except for the government”. I don’t think the people across Europe and Asia during World War II would agree either.

Your new government does not and cannot trust you. You pledged allegiance to your old country. Are you still secretly fighting for it? Or have you pledged allegiance to your new country? Does that mean anything when you betrayed your old country to whom you had pledged allegiance too? You’re a potential enemy and your new government will act accordingly.

I remember seeing a Mandelbrot program for the C64 where half the image was computed on the floppy drive because it's basically the same computer as the main C64. I think it had a 6502 instead of a 6510 and different memory.

I believe the Apple II floppy drive was "dumb", that is, controlled by the 6502 of the Apple II, so the machine couldn't do anything/much while loading/saving data. But the C64 + floppy drive was essentially a two-node distributed system.

I haven't used LLVM in ages. I think it injects references to functions in the CRT when you do certain operations in your code. _fltused is one of them, and I think _ftol? or something like that for floating point numbers is another one. There was also a "security cookie" at some point in the MSVC libs. Unfortunately, I don't remember the linker flags to get rid of that reference, IIRC it had to do with runtime stack checking.

These references do not appear in the .ll file. They are injected when the .ll file is compiled to object files.

I think something in your code triggers a reference to one of the other injected functions and that pulls in the CRT.

Try compiling your test file into an .o or .obj, that is, without linking. Then dump the symbols in the object file to see what symbols are referenced. I suspect you'll see other references to symbols in CRT and you will have to replace those as well with stubs.

Unfortunately, I don't remember the linker flags to replace/suppress the default CRT libs. Well, actually, you might compile to .o / .obj and then manually link on your system. If you're using MSVC check the options to its "link" executable (I don't remember the exact name of the MSVC linker).

I'm German, I don't speak Dutch. But I was able to follow a Dutch tour guide in Den Haag just fine when she was explaining things in Dutch. She kindly repeated everything in English for my benefit (I was the only foreigner) even though I told her I understood her just fine in Dutch.

You have to "adjust your ears" a bit but I think if you know German and English then you can understand Dutch just fine if it's not slang.

Does it make sense to change direction at this point? I envy PhDs working on self-driving cars and rockets and AI.

You don’t need a PhD to work on rockets. Well, you might depending on what you want to do.

There are a lot of software opportunities at rocket companies from test systems, real-time measurements, operator interfaces, flight simulation, and various other internal supporting software.

You might be interested in and have the right experience for, for example, operator interfaces and various internal dashboards and database applications. That might be your entry into the field and you can try to branch out from there into other areas.

I'm having a lot of fun running Fedora in a VM with UTM on my MacBook (an old Intel one). You might try that if you already have an M1 MacBook.

I believe Kochenderfer et.al.'s book "Algorithms for decision making" is also about reinforcement learning and related approaches. Free PDFs are available at https://algorithmsbook.com

It’s the title of the blog post and I didn’t want to change it. But yes, it seems to focus on the specific subset of hardware engineering that’s control systems.

I have been eyeing “The Hitchhiker's Guide to Logical Verification” but haven’t yet found the time to work through it.

The 2025 edition material is at https://github.com/lean-forward/logical_verification_2025?ta...

An older version (2022-2023) with video lectures is at https://lean-forward.github.io/logical-verification/2022/ind...

This is really good. I like the idea of the game and your execution of it is superb.

(Original title shortened because it's too long.)

Why higher-order logic is a good formalisation for specifying and verifying hardware

Mike Gordon

September 1985, 28 pages

DOI https://doi.org/10.48456/tr-77

Abstract

Higher order logic was originally developed as a foundation for mathematics. In this paper we show how it can be used as: 1. a hardware description language, and 2. a formalism for proving that designs meet their specifications.

Examples are given which illustrate various specification and verification techniques. These include a CMOS inverter, a CMOS full adder, an n-bit ripple-carry adder, a sequential multiplier and an edge-triggered D-type register.

See also https://lawrencecpaulson.github.io/2023/01/04/Hardware_Verif... and "Interactive Formal Verification, Lecture 11: Hardware Verification" by Lawrence Paulson https://www.youtube.com/watch?v=KVdgoEpo4uI&list=PLVdBoNna-4...