Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Mon, 10 Jun 2024 19:02:58 +0000
Organization: Rocksolid Light
Message-ID: <ccc9f6fa562ba6b8dee15f2c950ce4f4@www.novabbs.org>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com> <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3789889"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$A8/t5Q7kWMv/DRjBATzIIue.hccySsD0UT1Z9uo0VGMye3mXctKZq
Bytes: 2737
Lines: 41

Anton Ertl wrote:

> John Savard <quadibloc@servername.invalid> writes:

>>So allowing the processor to run code with out-of-order execution
>>turned off for that code is a way to limit the performance loss to the
>>untrusted code.

> Your trust in "trusted code" is unfounded.

Indeed.

>>And this would work well on my Concertina II architecture, where VLIW
>>features, such as the break bit, and extended register banks of 128
>>registers each, are present. Code can be generated that avoids
>>register hazards when run in order.

> How do "register hazards" come into play?

Registers values must appear to have been read and written as if the
instruction stream was processed sequentially. This is the vonNeumann
paradigm.

> But I have seen similar trains of thoughts several times from static
> scheduling advocates.  They see Spectre as the opportunity to tout
> their uncompetetive solutions by advocating solutions (like disabling
> speculation) that maximize the performance loss.

My 66000 has made no such claim..........on static scheduling.
My 66000 intends to have both In Order implementations and 
Great Big Out of Order implementation.

But a funny thing happens when the ISA is sufficiently expressive
such as my universal constants implementation::

You lose a lot of instructions that are easily scheduled, sometimes
to the point all you have left is the instructions at the core of the
algorithm. I have several subroutines with 30-40 FMAC FU instructions 
in a row without anything else to do. No amount of code scheduling or
OoOness helps these cases.

> - anton