Brendan (btrotter.delete@this.gmail.com) on June 30, 2022 3:52 pm wrote:
> Hi,
>
> dmcq (dmcq.delete@this.fano.co.uk) on June 30, 2022 11:20 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on June 30, 2022 11:09 am wrote:
> > > Kester L (nobody.delete@this.nothing.com) on June 29, 2022 1:49 pm wrote:
> > > > https://queue.acm.org/detail.cfm?id=3534854
> > > >
> > > >

> > > > The linear address space as a concept is unsafe at any speed, and it badly needs mandatory CHERI
> > > > seat belts. But even better would be to get rid of linear address spaces entirely and go back to
> > > > the future, as successfully implemented in the Rational R1000 computer 30-plus years ago.
> > > >

> > > >
> > > > Your thoughts on this article? I was under the impression that a lot of the 80s attempts
> > > > at capability machines (or really, anything that wasn't trying to be a glorified PDP-11)
> > > > floundered because of performance and cost issues (i.e. the Intel i432).
> > >
> > > My thoughts on the article itself is that it has a strong "marketing" smell. Let's
> > > ignore the article's words and focus on the "safety vs. performance" question.
> > >
> > > You can split it into 2 very different problems:
> > >
> > > a) Reducing the amount of developer effort required to create correct and efficient software
> > >
> > > b) Maximizing the efficiency (performance per watt per $) for normal
> > > users (not software developers) executing correct software
> > >
> > > For the former, the latter is mostly irrelevant. E.g. if you're running a specially instrumented
> > > "debug version" (with lots of extra checks enabled) in a special environment (e.g. under valgrind)
> > > and its 200 times slower, most developers simply won't have a reason to care.
> > >
> > > For the latter, the former is mostly irrelevant. The only thing you actually care about is protecting
> > > everything (kernel, other processes) from untrusted (potentially deliberately malicious) code;
> > > and for this you only care about the boundaries between "inside the process" and "outside the
> > > process" (and you do not care about anything inside the process trashing anything else in the
> > > process). For modern systems this is invariably done with paravirtualization - a process runs
> > > inside its own virtual machine (with virtual memory, virtual CPUs/threads, highly abstracted virtual
> > > IO like "open()" and "write()" instead of anything resembling physical devices).
> > >
> > > You can't/shouldn't combine these problems; because as soon as you do you're forcing a compromise (worse
> > > safety for the former and/or worse efficiency for the latter). Anyone who doesn't seem to understand this
> > > (e.g. CHERI designers) are trying to solve a problem without understanding the nature of the problem.
> > >
> > > However; there is some overlap. Good software developers try to create correct and efficient software (and
> > > not just correct software). Anything intended to reduce the effort needed to create correct and efficient
> > > software should/must be able to handle all the tricks that
> > > could be used to improve the efficiency of correct
> > > code. This includes using raw assembly language for highly specialized pieces; and self-modifying code and
> > > run-time code generation; and improving locality by using a single memory allocation for several objects of
> > > different types; and improving SIMD performance by using "structure
> > > of arrays" instead of "array of structures/objects";
> > > and recognizing that sometimes the same object has different types in different places (a pointer/reference
> > > to a structure/object that is used as a raw integer when calculating a hash, a "big integer" in one place
> > > that is an array of unsigned integers in another place, multiple inheritance, etc).
> >
> > I think your idea of 'normal users' needs a bit of refining.
>
> For "for normal users (not software developers)" I mean the 6+ billion people on the planet that
> use computers without ever writing a single line of code themselves, without knowing how a computer
> works, and without even knowing they're using a computer in some cases (e.g. driving a car).
>
> > I'm not sure there's many people left
> > who a company would pay after they're allowed to do the sort of tricks you're talking about. Do you
> > mean ners=ds who are just developing a program for themselves and waste their lives to no profit?
>
> All of those tricks happen in every computer I ever saw. The Linux kernel alone does most
> of them (not sure if eBPF has advanced to the "run-time generated code" stage yet).
>
> - Brendan

'Good developers try'. Well I can't argue with that. But do they succeed? And the Linux kernel has done a good job removing the masses of asm macros that were originally put in. The things you talk about are things that are being done by improving the language so making the faciities available in a less buggy way. Someone going around by hand changing an array of struct to a number of different arrays by hand is someone who is desperate. They'll spend a lot of time on it and generate lots of bugs and yes it would be much better if there was software support in the language they were using instead. The only people who'd normally do that by hand are people with time to waste and are not concerned about bugs. Not good developers. You're mixing up desperation and desire.