On Saturday, January 22, 2022 at 1:36:41 AM UTC-7, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:

> > Mill is competing against 3 giants that are willing and able to sell at ½ their
> > production costs for years at a time,

> Do you have a source for that?

While it is true that antitrust laws would be broken if they sold chips below
the marginal cost of production, that's so low that the issue would never arise.
It will be easy enough to torpedo the competition by allocating the huge
*development* costs of any processor design away from designs facing
competition.

As far as selling a product at... a low price relative to its marginal cost of
production... one example is the Vega 56 and Vega 64 video cards from AMD,
which were sold at consumer video card prices, despite incorporating what
was then usually the very expensive technology of HBM.

John Savard

Stephen Fuld wrote:
> It is a two source, one result instruction, but uses the carry register
> for an additional source and destination.  The syntax is
>
>     LBF    Result register, field length (in bits), buffer starting
> address (in bytes)
>
> The carry register contains the offset, in bits, from the start of the
> buffer where the desired field starts.
>
> The instruction computes the start of the desired field by adding the
> high order all but three bits of the carry register to get the starting
> byte number, then uses the low order three bits to get the starting bit
> number.  The instruction extracts the field, starting at the computed
> bit address with length as given in the register specified in the
> register, and right justifies that field in the result register.  The
> higher order bits in the result register are set to zero.  If the output
> bit of the Carry instruction is set, the length value is added to the
> Carry register.
>
> In order to speed up this instruction, and given that it will frequently
> occur in a fairly tight loop, I think (hope) that the hardware can take
> advantage of the “streaming” buffers otherwise used for VVM operations.
> Anyway, if one had this instruction, the main loop in the code above
> could be something like
>
>
> loop:
>     LDUB        R10,[R1+R9]
>     CARRY         R6,IO
>     LBF        R12,R10,R2     ;I am not sure about R2,  It should be
> the start of the packed buffer.
>     STD        R12,[R3+R9<<3]
>     ADD        R9,R9,#1
>      CMP        R11,R9,R4
>      BLT        R11,loop

That is really quite nice.
>
> For a savings of about 10 instructions in the I cache, but fewer in
> execution (but still significant) depending upon how often the
> instructions under the predicate are executed.
>
>
> Anyway, Of course, I invite comments, criticisms, etc.  One obvious
> drawback is that this only addresses the "decompression" side.  While I
> briefly considered a "Store Bit Field", I discarded it as it seemed too
> complex, and presumably would used less frequently, as
> compression/coding happens less frequently than decompression/decoding.

Encoding is almost always far easier than decoding, since there are zero
surprises when encoding. Yes, for codecs/compression it can be a _lot_
of work to figure out a near-optimal encoding, but the actual conversion
of the selected option into a bit stream is easy.

I.e. just like writing JSON or XML is trivial, while decoding is
somewhere between "some work" and "very hard".

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Friday, January 21, 2022 at 7:51:14 PM UTC-7, Ivan Godard wrote:
>
>> Something I learned a long time ago: there is a difference between the
>> first and the second sale of any product. To get the first sale you must
>> give them what they want. To get the second sale you must have given
>> them what they needed.
>
> That is very true. And since the first sale is a prerequisite for the second
> sale... you have to solve the very difficult problem of giving them *both*
> what they want and what they need, and yet at a competitive price.

Unless you're Microsoft.

Their strategy has always been to be to the market early, with a
buggy product, and have customers locked in fast.

Once people are used to a program, they usually do not want
to change, and Microsoft takes full advantage of that.

Quadibloc <jsavard@ecn.ab.ca> writes:
>Of course, microprocessors are made by *microprocessor*
>companies, and while their current offerings have mainframe power,
>these companies got their start making 8-bit (or even smaller)
>machines, which of necessity had few frills, and thus were of a
>minicomputer-like architecture, which tended to be in the 'scientific'
>rather than 'commercial' category. And at the beginning, maximum
>performance was desperately sought, so a culture was established.

You want the reader to think that microprocessors from microprocessor
manufacturers are less reliable than mainframes of old.

Reality check:

I have no experience with IBM mainframes, but I have experience with
DEC Alpha, which was the replacement for the VAX, where the high-end
parts were considered to be mainframes (and were often also used for
the same purposes, i.e., payroll and accounting, not for scientific
computing); likewise, the IBM S/360 was intended and used for both
scientific and business computing; e.g., NASA used 360s not just for
payroll and accounting.

Anyway, our Alphas running Digital OSF/1 (later later Digital Unix;
later Tru64 Unix) hung now and then, one time losing data
<http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html>
(admittedly, due to Berkeley's FFS; never had that with AdvFS). If we
saw a year of uptime, that was cause for celebration.

We later switched to Linux without seeing much of a difference in
stability (but then, we had seen a rise in stability earlier).

Anyway, we later switched to systems with Intel and AMD CPUs (often
low-end server boards, sometimes plain desktop boards) running Linux,
and they tend to be quite stable; we have seen uptimes of three years,
and the typical reason for downtime is a scheduled power outage or a
software upgrade, rarely a hang.

When we got an Odroid C2 and it often hung after a few weeks, that was
like a throwback into earlier, worse times; but that seems to have
been due to software issues, because now it is relatively stable (last
downtime 249 days ago due to a power outage).

Anyway, it seems to me that the computer industry has matured across
the board, leading to more stability and reliability. Of course, you
can still buy additional reliability through redundancy, and we do so
(using ECC RAM and RAID-1), and IBM (and others) will sell you even
more if you pay for it, but that does not mean that the Intel and AMD
systems today are less reliable than, say, 1970s mainframes; there is
a reason why Tandem was successful for a while.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> writes:
>I wonder if all of the viruses, Spctr=C3=A9, Meltdown, RoP attacks have red=
>uced
>PC sales by more than a total of 37 chips ?

Probably not by much, thanks also to the competetive landscape. But I
think that if one of the manufacturers chose to close Spectre, and
then made this big in their marketing, it might win them quite a lot
of sales (and lose the other quite a lot).

Given that Alder Lake came out still vulnerable to Spectre 54 months
after Intel was informed of Spectre in June 2017, it seems that they
don't want to take this opportunity to have a USP for a while. We
will see with Zen 4 towards the end of the year whether AMD is wiser.

We have seen with Rowhammer that the DRAM industry seems to just want
to wait this out. They seem to think that Rowhammer-immune DRAM won't
sell. Does the CPU industry think the same about Spectre?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Saturday, January 22, 2022 at 7:42:18 AM UTC-6, Anton Ertl wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
> >Of course, microprocessors are made by *microprocessor*
> >companies, and while their current offerings have mainframe power,
> >these companies got their start making 8-bit (or even smaller)
> >machines, which of necessity had few frills, and thus were of a
> >minicomputer-like architecture, which tended to be in the 'scientific'
> >rather than 'commercial' category. And at the beginning, maximum
> >performance was desperately sought, so a culture was established.
> You want the reader to think that microprocessors from microprocessor
> manufacturers are less reliable than mainframes of old.
>
> Reality check:
>
> I have no experience with IBM mainframes, but I have experience with
> DEC Alpha, which was the replacement for the VAX, where the high-end
> parts were considered to be mainframes (and were often also used for
> the same purposes, i.e., payroll and accounting, not for scientific
> computing); likewise, the IBM S/360 was intended and used for both
> scientific and business computing; e.g., NASA used 360s not just for
> payroll and accounting.
>
> Anyway, our Alphas running Digital OSF/1 (later later Digital Unix;
> later Tru64 Unix) hung now and then, one time losing data
> <http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html>
> (admittedly, due to Berkeley's FFS; never had that with AdvFS). If we
> saw a year of uptime, that was cause for celebration.
>
> We later switched to Linux without seeing much of a difference in
> stability (but then, we had seen a rise in stability earlier).
>
> Anyway, we later switched to systems with Intel and AMD CPUs (often
> low-end server boards, sometimes plain desktop boards) running Linux,
> and they tend to be quite stable; we have seen uptimes of three years,
> and the typical reason for downtime is a scheduled power outage or a
> software upgrade, rarely a hang.
>
> When we got an Odroid C2 and it often hung after a few weeks, that was
> like a throwback into earlier, worse times; but that seems to have
> been due to software issues, because now it is relatively stable (last
> downtime 249 days ago due to a power outage).
>
> Anyway, it seems to me that the computer industry has matured across
> the board, leading to more stability and reliability. Of course, you
> can still buy additional reliability through redundancy, and we do so
> (using ECC RAM and RAID-1), and IBM (and others) will sell you even
> more if you pay for it, but that does not mean that the Intel and AMD
> systems today are less reliable than, say, 1970s mainframes; there is
> a reason why Tandem was successful for a while.
<
When we closed the doors at Ross Technology (circa 1999) we turned off
our main server. It had been up for 7 years and several months. It had had
the CPUs upgraded 3 times, and memory was 4× what we started with,
and yet it had never crashed even with a power transformer blowing up in
a spectacular way less than 1 block from the engineering building and
taking power out over most of a square mile.
<
Somebody did care about reliability--shame they never were a leader in
the performance department. And look where they are now......
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Quadibloc <jsavard@ecn.ab.ca> wrote:
>While it is true that antitrust laws would be broken if they sold
>chips below the marginal cost of production, that's so low that the
>issue would never arise. It will be easy enough to torpedo the
>competition by allocating the huge *development* costs of any
>processor design away from designs facing competition.
>
>As far as selling a product at... a low price relative to its
>marginal cost of production... one example is the Vega 56 and Vega 64
>video cards from AMD, which were sold at consumer video card prices,
>despite incorporating what was then usually the very expensive
>technology of HBM.

The usual AMD GPU example for this is the Radeon VII, not the Vega's.

AMD's partner sold a significant number of Vega 56 and 64 cards and
they were available for an extended period, neither are behaviors one
would expect if they were making a loss on them (counting only
marginal costs).

Contributing to this was of course that AMD had other uses for the
"best" Vega 10 chips in far more expensive cards like Pro and Instinct
models, but I consider it likely that if AMD had actually lost money
on them they'd likely would have discontinued them quicker

Yes, they might well have assigned most or all of the chip production
cost to the "better" chips that went into the expensive products, but
how to budget that is one of those things that can always argued
either way.

The Radeon VII on the other hand was only sold directly by AMD (no
partners needing a cut) and was only available for a much shorter
period and in very low numbers.

Various industry experts guestimated the Radeon VII BOM cost at launch
as high as $650! which is of course insane for a $699 MSRP card and at
that time graphics card DID often sell at MSRP.

Again AMD used the same Vega 20 chip into Radeon Pro and Instinct
cards that was sold at way, WAY higher prices and likely the VII's BOM
cost came down over time just as the Vega 56/64's BOM cost did but the
VII never saw a price cut, instead the product was withdrawn.

There were definitely speculations that the VII was sold below the
marginal cost at least at launch. But given how dominating Nvidia is
in the relevant markets they couldn't do much. And there was no other
competitors in that specific market it could hurt.

On Saturday, January 22, 2022 at 3:58:38 PM UTC+2, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >I wonder if all of the viruses, Spctr=C3=A9, Meltdown, RoP attacks have red=
> >uced
> >PC sales by more than a total of 37 chips ?
> Probably not by much, thanks also to the competetive landscape. But I
> think that if one of the manufacturers chose to close Spectre, and
> then made this big in their marketing, it might win them quite a lot
> of sales (and lose the other quite a lot).
>
> Given that Alder Lake came out still vulnerable to Spectre 54 months
> after Intel was informed of Spectre in June 2017, it seems that they
> don't want to take this opportunity to have a USP for a while. We
> will see with Zen 4 towards the end of the year whether AMD is wiser.
>
> We have seen with Rowhammer that the DRAM industry seems to just want
> to wait this out. They seem to think that Rowhammer-immune DRAM won't
> sell. Does the CPU industry think the same about Spectre?
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.

On Saturday, January 22, 2022 at 2:58:27 PM UTC-6, Michael S wrote:
> On Saturday, January 22, 2022 at 3:58:38 PM UTC+2, Anton Ertl wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> > >I wonder if all of the viruses, Spctr=C3=A9, Meltdown, RoP attacks have red=
> > >uced
> > >PC sales by more than a total of 37 chips ?
> > Probably not by much, thanks also to the competetive landscape. But I
> > think that if one of the manufacturers chose to close Spectre, and
> > then made this big in their marketing, it might win them quite a lot
> > of sales (and lose the other quite a lot).
> >
> > Given that Alder Lake came out still vulnerable to Spectre 54 months
> > after Intel was informed of Spectre in June 2017, it seems that they
> > don't want to take this opportunity to have a USP for a while. We
> > will see with Zen 4 towards the end of the year whether AMD is wiser.
> >
> > We have seen with Rowhammer that the DRAM industry seems to just want
> > to wait this out. They seem to think that Rowhammer-immune DRAM won't
> > sell. Does the CPU industry think the same about Spectre?
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
<
> I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
<
Yes, it can; and at low HW costs and virtually zero performance impact.
We (this NG) discussed this back when Spectré was brand new.
<
The trick is to not update any microarchitectural state until the cause of
the state update has retired--and then to retire all instructions at uniform
speed. This includes cache data, cache tags, TLB state, TableWalk
accelerator state, and branch prediction state,...
<
Also, the processor cannot AGEN a new address based on data that took
a miss (tag or TLB) in the cache and access the cache with this unwarranted
address. This ends up providing a minimum lower bound (in gate delays) for
forwarding of LDed data. Many of the Spectré sensitive processors are operating
below this minimum gate delay figure.

Ivan Godard <ivan@millcomputing.com> schrieb:

> That is what the Mill encoding does: pure sources (loads, constants,
> streamers) have explicit width arguments in the asm and the encoding,
> while all other instructions take the width as tracked through the
> producer-consumer relationships of the program as executed.

What is a streamer?

On 1/22/2022 12:51 PM, John Dallman wrote:
> In article <ssg700$tgs$1@dont-email.me>, ivan@millcomputing.com (Ivan
> Godard) wrote:
>
>> At that point, if we do it right, our second sale advantage will
>> kick in and we should have a defensible (although possibly small)
>> economic position. I'd prefer better, but 1% of the world CPU
>> market sounds pretty good.
>
> Is that enough to get software vendors to support the platform?
>
> Indeed, what is your strategy for getting your processors to market? Is
> it still to be a fabless semiconductor vendor?
>
> John

You know what a fab costs? We will be fabless.

If we can't sell chips we can sell IP.

On 1/22/2022 2:20 PM, MitchAlsup wrote:
> On Saturday, January 22, 2022 at 2:58:27 PM UTC-6, Michael S wrote:
>> On Saturday, January 22, 2022 at 3:58:38 PM UTC+2, Anton Ertl wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>> I wonder if all of the viruses, Spctr=C3=A9, Meltdown, RoP attacks have red=
>>>> uced
>>>> PC sales by more than a total of 37 chips ?
>>> Probably not by much, thanks also to the competetive landscape. But I
>>> think that if one of the manufacturers chose to close Spectre, and
>>> then made this big in their marketing, it might win them quite a lot
>>> of sales (and lose the other quite a lot).
>>>
>>> Given that Alder Lake came out still vulnerable to Spectre 54 months
>>> after Intel was informed of Spectre in June 2017, it seems that they
>>> don't want to take this opportunity to have a USP for a while. We
>>> will see with Zen 4 towards the end of the year whether AMD is wiser.
>>>
>>> We have seen with Rowhammer that the DRAM industry seems to just want
>>> to wait this out. They seem to think that Rowhammer-immune DRAM won't
>>> sell. Does the CPU industry think the same about Spectre?
>>> - anton
>>> --
>>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> <
>> I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
> <
> Yes, it can; and at low HW costs and virtually zero performance impact.
> We (this NG) discussed this back when Spectré was brand new.
> <
> The trick is to not update any microarchitectural state until the cause of
> the state update has retired--and then to retire all instructions at uniform
> speed. This includes cache data, cache tags, TLB state, TableWalk
> accelerator state, and branch prediction state,...
> <
> Also, the processor cannot AGEN a new address based on data that took
> a miss (tag or TLB) in the cache and access the cache with this unwarranted
> address. This ends up providing a minimum lower bound (in gate delays) for
> forwarding of LDed data. Many of the Spectré sensitive processors are operating
> below this minimum gate delay figure.

And all that is somewhat easier in an in-order static scheduled chip.

On 1/22/2022 2:22 PM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> That is what the Mill encoding does: pure sources (loads, constants,
>> streamers) have explicit width arguments in the asm and the encoding,
>> while all other instructions take the width as tracked through the
>> producer-consumer relationships of the program as executed.
>
> What is a streamer?

Another spelling of NYF :-)

Michael S <already5chosen@yahoo.com> writes:
>I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.

We have described here in January 2018 (and repeated it later) how to
fix Spectre (all versions): Just treat microarchitectural state like
they treat architectural state: only make it visible to the outside on
commit, and throw it away on misprediction.

I think this can be achieved with little performance degradation for
most workloads; it will cost hardware (not huge amounts, but still)
and some design effort.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Torbjorn Lindgren <tl@none.invalid> writes:
>AMD's partner sold a significant number of Vega 56 and 64 cards and
>they were available for an extended period, neither are behaviors one
>would expect if they were making a loss on them (counting only
>marginal costs).
>
>Contributing to this was of course that AMD had other uses for the
>"best" Vega 10 chips in far more expensive cards like Pro and Instinct
>models, but I consider it likely that if AMD had actually lost money
>on them they'd likely would have discontinued them quicker

Yes, I expect that the revenue from the high-priced cards was small
compared to the revenue from the consumer models (so it would be hard
to use this revenue to make up for losses on the consumer model). I
also expect that a lot of the extra price went into driver development
and support, so the margin probably was not that much better.

>The Radeon VII on the other hand was only sold directly by AMD (no
>partners needing a cut) and was only available for a much shorter
>period and in very low numbers.
>
>Various industry experts guestimated the Radeon VII BOM cost at launch
>as high as $650! which is of course insane for a $699 MSRP card and at
>that time graphics card DID often sell at MSRP.
>
>Again AMD used the same Vega 20 chip into Radeon Pro and Instinct
>cards that was sold at way, WAY higher prices and likely the VII's BOM
>cost came down over time just as the Vega 56/64's BOM cost did but the
>VII never saw a price cut, instead the product was withdrawn.
>
>There were definitely speculations that the VII was sold below the
>marginal cost at least at launch. But given how dominating Nvidia is
>in the relevant markets they couldn't do much. And there was no other
>competitors in that specific market it could hurt.

The Radeon VII was a pretty low-key launch into consumer space, so I
guess they originally did not plan to go there; maybe they found that
they had more good chips than they could sell in high-priced cards
(this was their first foray into 7nm, and with a big chip, so they may
have ordered more wafers to cater for potential yield problems), and
so decided to sell some into consumer space. But of course there were
not enough chips to make the usual approach of selling chips to
partners rather than cards worthwhile.

Given the low-key launch, this launch was probably not for marketing
reasons, so I expect that they made a profit on these cards (otherwise
they would not have sold them at all).

The Radeon VII was withdrawn shortly after the RX 5700XT came out,
which was a signicant price/performance improvement over the Radeon
VII, and close enough in gaming performance to make the Radeon VII
pointless.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Saturday, January 22, 2022 at 6:58:38 AM UTC-7, Anton Ertl wrote:
> They seem to think that Rowhammer-immune DRAM won't
> sell. Does the CPU industry think the same about Spectre?

It depends. If DRAM could be made immune to Rowhammer,
or CPUs immune to Spectre-related attacks, at a cost of no more
than 1/2 of 1% loss in performance, and maybe a 5% increase in
cost... it would sell like hotcakes.

But given the actual likely impact on performance of making
memory immune to Rowhammer, and CPUs immune to Spectre...
"just won't sell" is, I'm afraid, entirely accurate; even if it were
what the customer needed, it isn't what the customer wants.

If you could get away with guarding the perimeter, while letting
the inside, where the work gets done, be insecure, because everything
that connects to the outside world is secure, you could have security
without much performance impact. While it is likely that one can only
achieve an illusion of security this way, for a number of reasons, if
that could be made to work, it would be highly attractive.

John Savard

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 1/22/2022 2:22 PM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> That is what the Mill encoding does: pure sources (loads, constants,
>>> streamers) have explicit width arguments in the asm and the encoding,
>>> while all other instructions take the width as tracked through the
>>> producer-consumer relationships of the program as executed.
>>
>> What is a streamer?
>
> Another spelling of NYF :-)

Ah, the Norwegian Occupational Hygiene Association.

They should be a pure source (who else?).

On Sunday, January 23, 2022 at 1:31:58 AM UTC+2, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
> We have described here in January 2018 (and repeated it later) how to
> fix Spectre (all versions): Just treat microarchitectural state like
> they treat architectural state: only make it visible to the outside on
> commit, and throw it away on misprediction.
>
> I think this can be achieved with little performance degradation for
> most workloads; it will cost hardware (not huge amounts, but still)
> and some design effort.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

I read these discussions. Found all proposals unconvincing.
They all appear to either underestimate performance cost of not doing load
that is based on result of speculated load or underestimate area cost of circuit
that completly undo side-effects of such "twice-speculated" loads.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 1/21/2022 7:25 PM, MitchAlsup wrote:

>> Thus, it seems like 99.996% of chip sales are independent of your argument
>> that RAS sells. It may, but not in the volume needed to compete to the point
>> where your production costs are comparable with their sales prices.
>
> All true.
>
> It's clear that there exists a market in which RAS sells; the question
> is the size of that market and its price elasticity
> (https://en.wikipedia.org/wiki/Elasticity_(economics)). There are other
> inelastic niche markets that we could own too; maximal single thread for
> example.

That sounds as if you were aiming for what is left of the mainframe
market.

You have a compiler, I understand, based on LLVM. Do you plan to
charge for the compiler?

What about an operating system? You will not be able to use
gcc as long as you do not put your compiler code under the GPL,
so Linux is probably out. One of the BSD variants, maybe.

What about application software? If you have high single thread
performance and good security, then maybe the commercial field
may be a good application field. If you can persuade anybody to
run an SAP benchmark on your CPU, that could be interesting
(although SAP usually runs on Linux these days).

Does your ISA also offer better performance on FPGAs? If so,
a soft core might also be an option.

John Dallman <jgd@cix.co.uk> schrieb:
> In article <11441320-3ee4-4d79-ab20-d976f5b5072fn@googlegroups.com>,
> jsavard@ecn.ab.ca (Quadibloc) wrote:
>
>> It depends. If DRAM could be made immune to Rowhammer,
>> or CPUs immune to Spectre-related attacks, at a cost of no more
>> than 1/2 of 1% loss in performance, and maybe a 5% increase in
>> cost... it would sell like hotcakes.
>
> Those numbers will change if a security breach with a major commercial or
> regulatory impact is achieved via Spectre or Rowhammer. So far, that
> doesn't appear to have happened?

https://xkcd.com/2166/ comes to mind.

On So 23 Jan 2022 at 10:35, jgd@cix.co.uk (John Dallman) wrote:

> In article <11441320-3ee4-4d79-ab20-d976f5b5072fn@googlegroups.com>,
> jsavard@ecn.ab.ca (Quadibloc) wrote:
>
>> It depends. If DRAM could be made immune to Rowhammer,
>> or CPUs immune to Spectre-related attacks, at a cost of no more
>> than 1/2 of 1% loss in performance, and maybe a 5% increase in
>> cost... it would sell like hotcakes.
>
> Those numbers will change if a security breach with a major commercial or
> regulatory impact is achieved via Spectre or Rowhammer. So far, that
> doesn't appear to have happened?

I don't think so.
Look what happens every day with active directory and exchange!
And nothing ever changes - people regard it like a kind of natural
desaster.

'Andreas

> We have described here in January 2018 (and repeated it later) how to
> fix Spectre (all versions): Just treat microarchitectural state like
> they treat architectural state: only make it visible to the outside on
> commit, and throw it away on misprediction.

While I do believe it can be done I don't think it's as easy as
it sounds. More specifically it requires:
- A clear definition of "microarchitectural state".
- A clear definition of "the outside".
I think there is a lack of experience with such a viewpoint which makes
it hard to have a clear understanding of the real costs.

Stefan

On Sunday, January 23, 2022 at 4:09:03 AM UTC-6, Michael S wrote:
> On Sunday, January 23, 2022 at 1:31:58 AM UTC+2, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
> > We have described here in January 2018 (and repeated it later) how to
> > fix Spectre (all versions): Just treat microarchitectural state like
> > they treat architectural state: only make it visible to the outside on
> > commit, and throw it away on misprediction.
> >
> > I think this can be achieved with little performance degradation for
> > most workloads; it will cost hardware (not huge amounts, but still)
> > and some design effort.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
<
> I read these discussions. Found all proposals unconvincing.
> They all appear to either underestimate performance cost of not doing load
> that is based on result of speculated load or underestimate area cost of circuit
> that completly undo side-effects of such "twice-speculated" loads.
<
For my part: I have only been in on the teams that built 7 such chips,
so I am not without experience in that mater. I work in architecture, circuit
design, cell design, and layout; so I have a bit better understanding of the
whole of such "projects" than most. I have built in-order pipelines, score-
board designs, reservation station designs, trace cache designs, and have
patents in making transcendental calculations as fast as division:
<
Why is it that you find the arguments unconvincing ?

Michael S <already5chosen@yahoo.com> writes:
>On Sunday, January 23, 2022 at 1:31:58 AM UTC+2, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>> >I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
>> We have described here in January 2018 (and repeated it later) how to
>> fix Spectre (all versions): Just treat microarchitectural state like
>> they treat architectural state: only make it visible to the outside on
>> commit, and throw it away on misprediction.
>>
>> I think this can be achieved with little performance degradation for
>> most workloads; it will cost hardware (not huge amounts, but still)
>> and some design effort.
....
>I read these discussions. Found all proposals unconvincing.
>They all appear to either underestimate performance cost of not doing load
>that is based on result of speculated load

That's not the solution. As you rightly point out, that would slow
down execution too much.

>underestimate area cost of circuit
>that completly undo side-effects of such "twice-speculated" loads.

You don't undo the side-effects. Instead, you don't do the side
effects. You just keep the load buffers around until commit, and then
you update the L1 cache. And if the line is already in the L1 cache,
you only need to keep the info around that the line has been accessed
(for LRU).

How much area will that cost? The Skylake already has 72 load buffers
according to
<https://stackoverflow.com/questions/54876208/size-of-store-buffers-on-intel-hardware-what-exactly-is-a-store-buffer>
in order to implement the memory model. That's probably enough for
fixing the Spectre cache side channel without significant slowdown, so
the extra area for that fix should be miniscule. What makes you think
that we underestimate the area cost?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 1/23/2022 10:35 AM, Anton Ertl wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Sunday, January 23, 2022 at 1:31:58 AM UTC+2, Anton Ertl wrote:
>>> Michael S <already...@yahoo.com> writes:
>>>> I don't think that Spectre-V1 (bounds check bypass) can be solved in hardware without significant performance degradation on many important workloads.
>>> We have described here in January 2018 (and repeated it later) how to
>>> fix Spectre (all versions): Just treat microarchitectural state like
>>> they treat architectural state: only make it visible to the outside on
>>> commit, and throw it away on misprediction.
>>>
>>> I think this can be achieved with little performance degradation for
>>> most workloads; it will cost hardware (not huge amounts, but still)
>>> and some design effort.
> ...
>> I read these discussions. Found all proposals unconvincing.
>> They all appear to either underestimate performance cost of not doing load
>> that is based on result of speculated load
>
> That's not the solution. As you rightly point out, that would slow
> down execution too much.
>
>> underestimate area cost of circuit
>> that completly undo side-effects of such "twice-speculated" loads.
>
> You don't undo the side-effects. Instead, you don't do the side
> effects. You just keep the load buffers around until commit, and then
> you update the L1 cache. And if the line is already in the L1 cache,
> you only need to keep the info around that the line has been accessed
> (for LRU).

Yes, but that's hard to get right - the LRU can leak the reference too.