26 Jun
2018
26 Jun
'18
10:20 p.m.
On Jun 26, 2018, at 2:59 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Tue, Jun 26, 2018 at 05:54:32PM -0400, Ronald Natalie wrote:
I think you are more or less agreeing with the author. (I also think, as
Unix die hards, we all bridle a little when anyone dares to say anything
negative about C. We should resist that if it gets in the way of making
things better.)
With new attacks like TLBleed etc. it is becoming increasingly clear that
caching (hidden memory to continue with the illusion of a simple memory
model) itself is a potential security issue. I didn't think anything the
author said was particularly controversial any more. A lot of processor
evolution seems to have been to accommodate C's simple memory model.
What is remarkable is how long this illusion has been maintained and
how far we have gotten with it.
So I agree, had the same initial reaction. But I read the paper a
second time and the point about Fortran, all these years later, still
being a thing resonated. The hardware guys stand on their heads to
give us coherent caches.
Fortran is a higher level language. It gives he compiler more flexibility in deciding
what the programmer intended and how to automatically optimize for the platform.
C is often a ???You asked for it, you got it??? type paradigm/ The author at least has me thinking about how you
could make a C like
language that didn't ask as much from the hardware.
Erlang. Actor, vector & dataflow languages. Actually even C itself
can be used if it is used only on individual simple cores and instead
of caches any accessible memory is made explicit. Not sure if there
is a glue language for mapping & scheduling computation to a set of
simple cores with local memory and high speed links to their neighbors.