Einstein's Yak
Books about Apple or involving Apple are dangerous for me to read, as they tend to cause acute onsets of nostalgia. The latest case is David Pogue’s “Apple - The first 50 years.” I fortunately got over the point of purchasing an original Macintosh, but I don’t find it too hard to justify getting something more usable, like a ‘040 Mac, which can be used for Newton development! Danger was averted though, Einstein saved the day as I realized that it would make more sense to get back to some of the open items there.
Right now I am trying to clean up the serial port support, and promptly
ended up in yak shaving territory. The goal is to simplify building and
ideally also contributing to Einstein, and the different layers of yak
wool are: Getting the REx building process streamlines, making
building NewtonScript packages using tntk as simple as possible,
fixing package creation issues with DCL, and as the current step,
fixing function frame generation with NEWT/0. Side tracks are sorting
out GCC compiler issues, pondering the use of mosrun as part of the
build process, and wondering which code forge could support cross
platform builds. Good times!
What's old is new
Sometimes it’s nice to be wrong, seems we’re still good for a while:
arm-none-eabi-gcc: note: valid arguments are: armv4 armv4t armv5t
armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2
armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a
armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a
armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a iwmmxt iwmmxt2
GCC still supports armv4 which is what we need for our green friend!
On another note, GitHub makes me sadder and sadder. I tried to kick off a macOS build for GCC, it has been queued for eleven hours now, and it honestly looks dead. Alternatives are sparse for macOS builds, or even just arm64.
What's new is old
So we did get the ability to compile C++ programs for NewtonOS just a short six years ago, and now it seems that we’ll have to plan for it going away: GCC 8.5 was the last version to support ARMv4, and as such is already quite old. The challenge will be to find versions which run on Apple Silicon come 2027, when Rosetta will not be supported by Apple anymore…
Makes me wonder whether trying to either get CFront 2.1 working again, or use mosrun instead of fiddling with GCC cross compilation
This Changes Everything
I know, it’s a cliche phrase, but I think everything is indeed changed. Well, that’s maybe exaggerated, but in the field I’m active in, large language models (some call them artificial intelligence) are currently having a huge impact.
In my experience, they are heavily bending time used for the different phases of software engineering. Programming tasks which used to take hours or days (or even more) are now done in minutes. This allows to shift more time to other activities or allows to do more. But in some cases, it also requires more time to be spent on other phases, otherwise there will be trouble: Especially properly defined requirements and implementation validation are becoming extremely important.
One specific example concerns reverse engineering of the NewtonOS, something various people have been working on over the last twenty years and more. It is a slow process, requires a lot of time and dedication, and sometimes quite frustrating. But with LLMs, this changes - a lot. A year ago, I was still thinking we would need LLMs trained specifically on the available NewtonOS artifacts (DDK headers, ROM disassembly, ARM reference manuals), but things have changed over the last year.
I have been trying a more general approach to fill in the blanks, and it’s quite a ride. The output is still mediocre, but the more structure and data will be available, the better it will be. The approach works actually in all cases where the solution outline is mostly known:
Do not tell the LLM to solve the problem, but think how you would solve the problem, and instruct the LLM to do so.
For the reverse engineering task, this means to first put tools together which help, use the tools, evaluate the process, improve the tools, repeat. Here, this means to automate the extraction of methods, the derivation of vtables, the derivation of class layouts, and grunt work like resolving cross references. What is really interesting is to let the LLM reflect on the process and improve the tools along the way.