3 ms·
I really like these chip-level teardowns. It's fantastic to see how the code you write actually executes. On the Newton we were short of code space, and with a
by kabdib 11y ago
I really like these chip-level teardowns. It's fantastic to see how the code you write actually executes.
On the Newton we were short of code space, and with a 4MB ROM it was expensive (in bytes) to do "long" branches.
The ARM 610 we were using would fault on a "never" condition code (0xF....). So we replaced thousands of fat function calls each with a single 0xFxxxxxxx instruction that was dispatched by a simple fault handler; it was fast enough -- the ARM's exception handling is really good -- and even though ARM Ltd. wasn't willing to sanction what we were doing with their "undefined behavior" grey area, they weren't going to change the handling of "NV" on the 610, and this worked well enough to ship the first few versions of the Newt.
(The 68000 had a similar thing going on; all instructions starting with 0xAxxx or 0xFxxx would trap, so we used them to compress calls in the ROM on the Atari ST).
Fortunately memory is a lot less dear these days. (One recent project I was writing firmware for, I had a conversation that went like:
H/W engineer: "Sorry, but we're going to have to change the amount of memory the system has."
Me (apprehensive and internally ready to fight): "Okay..."
H/W: "Yeah, to save materials cost, we'll have to double it."
Me: "W00t?")
- msbarnett 11y ago> (The 68000 had a similar thing going on; all instructions starting with 0xAxxx or 0xFxxx would trap, so we used them to compress calls in the ROM on the Atari ST). This brings back memories of patching A-traps in classic Mac OS. Fundamentally the same mechanism -- OxA instructions would trap, the handler would consult a table in RAM to find the location in ROM for the system call. You could dynamically replace a system call's implementation by patching the lookup address for fun and profit.
- pm215 11y agoThe 610 faulting on NV condition codes is part of a journey of that bit of the instruction space from the original "really never executed, ie NOP" in the ARM1 (which just falls out of the implementation) through "this is unpredictable" (where UNDEF is a permitted implementation and helpful for flushing out stray applications relying on the old behaviour) until you get to the ARMv5 architecture, which uses the space for a collection of new instructions (which can't be conditional). A whole sixteenth of the encoding space turns out to be just too precious to waste.
- kabdib 11y agoNo question that 1/16th of the instruction space is precious. I was surprised that ARM hadn't used it for something, even as early as the ARM610.
- bigiain 11y agoHeh - I had that once too "This 2Gig of flash we've got specced here is kind of expensive." they said "Uh oh" I thought, "We can save nearly $2.50 if we replace it with 4Gig" they said "Ah hah! That'll solve my problem about how to safely download and install a new complete OS image!" :-) You gotta win _sometimes_…
- kabdib 11y agoClosely related: Bending heaven and earth to fit a bunch of functionality into 2048 bytes of code (the part costs 17 cents). A couple of weeks before shipping, hardware says "The part with 4096 bytes turns out to be cheaper. Do you want to use it?" My little team of two told them no (we'd done all our testing on the older part, and God only knows what bugs we'd find in the newer one...)