Port forwarding from RPi to Windows machine

Feb 05, 2024 Last reply: 2 years ago 43 Replies

There is _plenty_ of scope for an assembler to choose whatever opcodes it wants. Consider the simplest case of a NOP - some architectures have a specific NOP opcode, others it is simply a shorthand for an operation that does nothing, e.g. add 0 to a register and so on. Regardless there are plenty of alternatives that can be chosen. Things get more opaque once addressing modes, the size of jumps, immediate operands and so on are considered. I'm reminded of the warning in the A86 manual "this assembler generates a unique fingerprint in these cases, which I can detect in the binary whether you are registered or not".

There's a lot of mysticism that has been attached to that over the years, mostly by people who have never read the original report. It wasn't some magical AI code fairy that could identify that you were compiling any abstract compiler or login program and automatically conjure up appropriate code for the circumstances, it used fingerprinting IIRC at the token level (i.e. after the code is broken in to "words", but before parsing to figure out how those "words" are associated with each other). An independent implementation of functionally equivalent code, or even the same code after heavy edits over time, would not be affected.

No, it was designed for the Archimedes, pure and simple. The 8086 was already one the market thus the rest of the industry essentially leapfrogged 16 bit and jumped straight to 32 bit. To this day 16 bitters are few and far between. There's 8086-80286, MSP430, and... err... Well there's the original 68000 but that was 32 bit from a software viewpoint.

That's a very romanticised view, it often happens in science and engineering when one of the characters has an interesting personal story, Alan Turing and Stephen Hawking would be others that come to mind. The feature set was a committee effort, the high level design was Roger/Sophie Wilson and the low level Steve Furber. But as above, it was designed for the Archimedes, no more and no less.

The primary design objectives were a low per-unit cost (not design cost as sometimes stated) and a minimum of glue logic between major subsystems. I recall seeing a "triangle" diagram with the corners cut off, the centre of the triangle was the CPU, the corners were memory controller, graphics, and peripheral bus.

You're correct to identify a plastic package as a design criteria, from memory the target was £2/chip which implied that over a ceramic one. None of the group had any chip design experience, they knew a plastic package meant no more than a 1-2W power dissipation, but had no idea what that meant in terms of design. Thus they optimised for power at every opportunity and undercut the target by orders of magnitude.

The other dimension to lowering the cost of the package was reducing pin out to the bare minimum, hence the 24 bit (not 32 bit) address bus. Size of the wafer was an irrelevance since they never baked their own chips, die size yes they wanted to keep small to lower cost but not an over-riding consideration - it wasn't that much smaller than many other designs of the period.

This is from my lecture notes and also a couple of pints while at Uni 25 years ago. The lecturer for hardware design was none other than Steve Furber who co-designed and literally wrote the book on the thing.

That's about right - ARM1/ARM2 was designed specifically for the Archimedes, and various design decisions that remain in Aarch32 are because of specific constraints on that platform. For example ARM2 had no cache and was designed to make best use of FPM DRAM. Every instruction took two cycles except some where sequential memory accesses could be completed in a single cycle - hence LDM/STM instructions.

Matt Evans (another of Steve's former students) did a good talk on this at CCC a few years ago:

formatting link
Theo

I know what you mean there, but just to clarify, the majority of arithmetic instructions took one cycle (except an extra cycle when using shift by a register or where the PC was the destination, and multiplies were up to 3 cycles).

Memory loads and stores were two cycles, one to set up the transfer and one to do the transfer, but the memory system allowed a read or write to the next word in just one cycle. So the LDM and STM instructions were included which could transfer from 1 to 16 registers at a cost of 1 + number of registers transferred cycles (as long as it was within the same memory page). That did make quite a high upper bound on the interrupt latency though, which was an issue for real-time use.

Strange how I can remember that from 35 years ago, but then you only had to know a few classes of instruction timings in order to be able to write highly optimised assembler. It became more and more complex with each subsequent ARM generation, and has been best left to a compiler for quite a while.

---druck

That’s what they want you to think.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required