Motor generator

[Liam Proven]

On Thu, 6 May 2021 at 02:19, Jules Richardson via cctalk
<cctalk at classiccmp.org> wrote:
>
> I seem to recall an anecdote about Acorn hooking up the first prototype
> ARM-1 processor and it working, despite showing no current draw on the
> connected ammeter - it then transpired that the power supply was still
> switched off,  but it was so efficient that it was able to run via leakage
> current on the connected I/O lines.

Oh yes indeed.

Sophie Wilson did a talk at the last ROUGOL meeting, last month. Not
sure if the video is online yet. I can share it here when it's up if
folk are interested. There are a few stories of bring-up of the first
ARM chips that were remarkable.
* The unanticipatedly low power draw;
* Simulating the instruction set in BBC BASIC on a BBC Micro during
the design phase, instead of some vastly-expensive bigger system;
* The fact that the very first silicon worked very nearly perfectly first time;
* Embedding a `MANDEL` instruction into the BASIC for demos, because
people expected it so often that it was worth implementing someone's
algorithm in ARM code and putting it directly into the interpreter.

She's really quite pessimistic about the future of microprocessor manufacture.

She gleefully made fun of Intel quite a bit, but pointed out the
[cough] _inaccuracies_ and shall we say _over-enthusiastic_ claims of
their marketing materials concerning die size.

She's quite impressed with AMD's recent designs, which partition parts
of multicore processors into separate dies, so that only the bits that
really need it can be made on the very expensive tiny feature size
processes, and other bits on cheaper, larger feature sizes.

Oddly she barely mentioned Apple Silicon, merely that they were
extremely aggressive with wide superscalar designs and so on.

Her overall point being that although it _is_ possible for transistor
sizes etc to get a _little_ smaller than is mainstream now, the
industry is now at the point where smaller-feature-size, faster chips
are actually getting _more_ expensive to make, not less. We are very
nearly at the end of the line of high-end chips getting faster at all.

Part of this is due to language design. I noticed myself that in
recent decades, chips seem to be designed to run C fast, to put it
simply. Wilson feels that the instruction model of C is now a limiting
factor, and that one of the only ways to go is something akin to her
own FirePath processor design for Broadcom.

Firepath is more or less the "Son of ARM". Not much is public about
Firepath and this is one of the best references I know:
https://everything2.com/title/FirePath

It can do things like load 8 different bytes of data into a set of
registers, perform arithmetic on them, and depending on the result,
put the results back somewhere else or not, in a single assembler
opcode in a single cycle... and she feels that no contemporary
high-level language can usefully express such operations.

I suppose APL might come closest, but it's hardly mainstream.

I find it an interesting thought that once the only way to get more
performance will soon be to switch to radically different processor
architectures that always work in ways very loosely comparable to MMX
or Altivec (and their descendants), and write new programs in new
languages on new OSes that can exploit deep hardware parallelism.

The flipside of the coin may be that current, "traditional" designs
will get smaller and cheaper and use less power, and the only way to
squeeze better performance out of them will be to use smaller, simpler
OSes. There's a chance here for what the mainstream sees as obsolete
or irrelevant OSes and languages to enjoy a revival. The vanguard
could be VMS.

I'd love to see this.

I found it amusing after my FOSDEM talk in February, which talked
about this. I was talking about some of the ideas on the Squeak
Smalltalk mailing list. I listed a set of criteria I'd been using to
narrow down my selection of criteria:
• a clean, simple OS, with SMP support, that supported pre-emption,
memory management etc.
• in a type-safe language, with a native-object-code compiler — not
JITTed, not using a VM or runtime
• and a readable language, not something far outside the Algol family
of imperative HLLs
• that was portable across different architectures
• that was FOSS and could be forked
• that was documented and had a user community who knew it
• that can be built with FOSS tools (which RISC OS fails, for instance)
• which is or was used by non-specialists for general purpose computing
• which can usefully access the Internet
• which runs on commodity hardware
• which does not have a strongly filesystem-centric design that would
not fit a PMEM-only computer (i.e. not an xNix)

... and several people went "no, that is impossible. Match all of
those at once and you have the null set.

And I said, no, this is why I picked Oberon and A2. The result seemed
to be a number of people who hadn't been paying much attention sitting
up and asking what language/OS this was.

It was similar to trying to summarise what I'd learned about Lisp to a
Unix community in Another Place a few years ago. It all washed over
them until I quoted observations such as Alan Kay's "Lisp is the
Maxwell's Equations of programming languages", which made a few people
suddenly wake up and go read the links I was providing.

Some stuff may yet come back from obscurity. I hope. :-)

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053