[TynesideLUG] Your Computer is not a Fast PDP-11

[Alex Kavanagh]

Re-instating on the mailing list:

On Mon, 8 Feb 2021 at 14:46, Jeff Joshua Rollin <jeff at jeffjoshua.club>
wrote:

>
> On 08/02/2021 10:01, Alex Kavanagh wrote:
>
>
>
> On Sat, 6 Feb 2021 at 20:01, Jeff Joshua Rollin <jeff at jeffjoshua.club>
> <jeff at jeffjoshua.club> wrote:
>
>> Hi,
>>
>> I mentioned during today's LUG having read a paper a few years ago which
>> complained that modern C is still coded (and indeed the language was
>> designed) to expose a virtual PDP-11 to the programmer. I didn't think I
>> would find it again but, having Googled, I think I have. (If it's not
>> the same one, it basically touches on the same points.)
>>
>
> I don't think it is as clear cut as to say "modern C is still coded ... to
> expose a virtual PDP-11".  It *was* coded that way and inertia tends to
> maintain the design pattern because, simultaneously, during the last 40-odd
> years, processors have also been coded to a particular execution model to
> get the best performance out of the dominant systems language: C.  So they
> effectively seem to have locked each other into a vicious cycle of
> maintaining the status quo.
>
> It would have been interesting if the Transputer
> <https://en.wikipedia.org/wiki/Transputer> had made more of an impact, as
> it begat the concurrent programming languages occam (and occam 2).  But the
> ideas did end up in AMD/Intel in how to interlink CPUs and other chips
> together.
>
>
> Yes, it's slightly more complicated than that. Admittedly some of that
> article went a little bit over my head, but I'm learning.
>
> It will be interesting to see what happens with any of the current crop of
> operating systems being coded in Rust; I'm sure you're aware of at least
> some of them - and of course there's software other than OSes being coded
> in Rust too. IIUI correctly, the RISC-V ISA doesn't try to help programmers
> doing concurrency in any way, although to date I think their focus has
> mostly been in embedded systems where perhaps it's not as important as
> trying to keep multicore desktops and servers occupied as much as possible.
> It does allow for extensions, however, so perhaps in future they will end
> up having to add them. The fate of all (successful) ISAs seems to be to
> grow larger and larger...
>
> Had to look up the Transputer again. For some reason I thought it was
> based on multiple MC68K's; perhaps I'm thinking of something else, or
> perhaps it was because Atari tried their hand at one (the Atari ST and
> successors used MC68Ks, like pre-PowerPC Macs, Commodore Amigas, and early
> Suns). Yet another example of innovative technology being squashed by the
> market and economies of scale, I guess.
>

I don't think that Rust necessarily targets modern CPUs.  Obviously, it
wants to run on x86, but that has the (somewhat) ridiculously huge CISC
instruction set (tautology alert!).  So lots of Intel/AMD silicon goes to
taking CISC and making it RISC.  But to do it efficiently, you need a
really long pipeline (as there's lots of decoding steps to get those tasty
CISC instructions into lots of little, fast, edible RISC instructions).  So
now, with your really long pipeline (10s of instructions), you get
branches, which stall the pipeline.  So you have to to branch prediction,
which means running lots of speculative branches at the same time.  This
needs even more silicon, what with the extra registers sets (one per
branch), ALUs, Cache, etc.  And then when a branch finally comes good, you
have to do the whole 'rename' thing so that you can carry on predicting.

x86x processors do a huge amount of work, and compilers often have to work
with them just to get serious performance.  And strangely, doing it in
silicon was the fastest way to do it as compilers would be too slow to do
all that optimisation.  But, strangely now, CPUs are fast enough that
smart-compilers can now optimise code for RISC processors!  Hence ARM
cores, simple little things, can fly fast, churning through heavily
optimised code *faster* than x86 CPUs can.  And the silicon is cheaper.
Funny old world.

Anyway, back to Rust.  Rust doesn't target any particular processor.
Although the compiler has lots of intermediate representations (IR) one of
them is LLVM so that it can be compiled to ... x86 :)  Seriously, though,
that's just one of the IRs and other's are various stages of getting closer
to a machine level representation of the code, rather than the abstract
world of variables, iterators, functions, closures, traits, and types that
inhabit the language.  Rust seems to target a kind of a idealised
processor, but that you have to really care about how memory is allocated
and used; in that it is a strange 'high-level' language, as it cares about
ONE aspect of the low level; what the memory is.  But it doesn't really
care about the memory as you don't have to care *where it is*, just
that *memory
exists and you can't share it without being deliberate about it*.

Anyway, I'll stop here, before this turns into some kind of weird sub-child
of an email and blog post!

Cheers
Alex.


>
>
>> It's available online at https://queue.acm.org/detail.cfm?id=3212479 (no
>> charge), and there is also a link to a PDF of the article on the same
>> page.
>>
>> Hope this is of interest to someone,
>>
>> Jeff.
>>
>>
>> _______________________________________________
>> Tyneside mailing list
>> Tyneside at mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/tyneside
>>
>
>
> --
> Alex Kavanagh
> Home: http://alex.kavanagh.name
> @ajkavanagh
>
>

-- 
Alex Kavanagh
Home: http://alex.kavanagh.name
@ajkavanagh