On Saturday, April 24, 2021 at 12:15:40 PM UTC-6, Quadibloc wrote:
> On Thursday, April 22, 2021 at 2:26:58 PM UTC-6, gareth evans wrote:
>
> > I had already found that article but it does not cover
> > the 3A5000 which comes after the MIPS64 products
> The news item I saw about the Loongson 3A5000 confirms
> that it has a new ISA, and is not a copy of the MIPS or the
> Alpha like some Chinese chips. However, it also noted that the
> ISA had only been disclosed, at this time, to select business
> partners of Loongson, so it isn't available on the Internet at this
> time.

Here is the article that I saw:

https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture

They could have used POWER instead :-)

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture
>
> They could have used POWER instead :-)

No, Power does not have load/store pair, without which you cannot compete
on the high end today.

The antique RISC instruction sets are now officially dead going forward.

Which begs the question of whether the all the instruction sets proposed
here support load/store pair...

Brett <ggtgp@yahoo.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>>> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture
>>
>> They could have used POWER instead :-)
>
> No, Power does not have load/store pair, without which you cannot compete
> on the high end today.

You mean something like

# Load VSX Vector instructions load a quadword from
# storage as a vector of 16 byte elements, 8 halfword
# elements, 4 word elements, 2 doubleword elements or
# a quadword element into a VSR.

?

Granted, it's from the not yet implemented 3.1 ISA, and it is
a prefixed instruction.

> The antique RISC instruction sets are now officially dead going forward.

It still seems to be alive :-)

On Thursday, April 29, 2021 at 12:03:05 AM UTC-5, gg...@yahoo.com wrote:
> Thomas Koenig <tko...@netcologne.de> wrote:
> > Quadibloc <jsa...@ecn.ab.ca> schrieb:
> >> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture
> >
> > They could have used POWER instead :-)
> No, Power does not have load/store pair, without which you cannot compete
> on the high end today.
>
> The antique RISC instruction sets are now officially dead going forward.
<
They were dead by 2005, but they just hadn't noticed it yet.
>
> Which begs the question of whether the all the instruction sets proposed
> here support load/store pair...

Does LM (Load Multiple) and SM (Store Multiple) and MM (Move Memory)
Qualify ?

On Thursday, April 29, 2021 at 8:51:13 AM UTC+3, Thomas Koenig wrote:
> Brett <gg...@yahoo.com> schrieb:
> > Thomas Koenig <tko...@netcologne.de> wrote:
> >> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> >>> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture
> >>
> >> They could have used POWER instead :-)
> >
> > No, Power does not have load/store pair, without which you cannot compete
> > on the high end today.
> You mean something like
>
> # Load VSX Vector instructions load a quadword from
> # storage as a vector of 16 byte elements, 8 halfword
> # elements, 4 word elements, 2 doubleword elements or
> # a quadword element into a VSR.
>
> ?

No, he means Load/store pair in aarch64 style.
For load:
Rd0 = Eff_addr[0], Rd1 = Eff_addr[1]
For store:
Eff_addr[0]= Rs0, Eff_addr[1] = Rs1

IBM's new prefixed load/store instructions are just way of fitting very wide (34b, if I am not mistaken) immediate displacement into what once was fixed-width ISA.
More like move in x86 direction than in aarch64 direction.

>
> Granted, it's from the not yet implemented 3.1 ISA, and it is
> a prefixed instruction.
> > The antique RISC instruction sets are now officially dead going forward.
> It still seems to be alive :-)

You don't understand Brett's definition of "officially dead".
"Officially dead" == not used by Apple and unlikely, in his opinion, to be used by Apple in foreseeable future.

Michael S <already5chosen@yahoo.com> wrote:
> On Thursday, April 29, 2021 at 8:51:13 AM UTC+3, Thomas Koenig wrote:
>> Brett <gg...@yahoo.com> schrieb:
>>> Thomas Koenig <tko...@netcologne.de> wrote:
>>>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>>>>> https://www.tomshardware.com/news/loongson-technology-develops-its-own-cpu-instruction-set-architecture
>>>>>
>>>>
>>>> They could have used POWER instead :-)
>>>
>>> No, Power does not have load/store pair, without which you cannot compete
>>> on the high end today.
>> You mean something like
>>
>> # Load VSX Vector instructions load a quadword from
>> # storage as a vector of 16 byte elements, 8 halfword
>> # elements, 4 word elements, 2 doubleword elements or
>> # a quadword element into a VSR.
>>
>> ?
>
> No, he means Load/store pair in aarch64 style.
> For load:
> Rd0 = Eff_addr[0], Rd1 = Eff_addr[1]
> For store:
> Eff_addr[0]= Rs0, Eff_addr[1] = Rs1
>
> IBM's new prefixed load/store instructions are just way of fitting very
> wide (34b, if I am not mistaken) immediate displacement into what once was fixed-width ISA.
> More like move in x86 direction than in aarch64 direction.
>
>>
>> Granted, it's from the not yet implemented 3.1 ISA, and it is
>> a prefixed instruction.
>>> The antique RISC instruction sets are now officially dead going forward.
>> It still seems to be alive :-)
>
> You don't understand Brett's definition of "officially dead".
> "Officially dead" == not used by Apple and unlikely, in his opinion, to
> be used by Apple in foreseeable future.

That is unfair, I am not that big an Apple fanboy.
Apple switched to Intel in 2005 and in 2009 ended PowerPC support.
“Apple released Mac OS X v10. 6 "Snow Leopard" on August 28, 2009 as
Intel-only”.

I did not declare PowerPC and all antique RISC’s dead on either of these
dates.
RISC has an obvious price and die size advantage over x86 and was very much
alive.

Antique RISC (as opposed to modern RISC) died when MIPS died, that is when
ARM8 went down market, and RISC-V went mass market. Leaving no market for
outdated architectures besides legacy compatibility decline. Free RISC-V or
fast ARM8, make your pick.

There is some room for cheaper than ARM8 license but fast in the middle,
it’s a tight squeeze that Mill and others here are trying to fit. Sucks to
be clearly better but have little or no market.

But here is some hope, do you want your car to run ARM8 so every hacker on
the planet can hack your car, or something different?

There is room for other instruction encodings if for only this reason, it
keeps POWER alive for IBM and will make a small market for Loongson in
China.

On Friday, April 30, 2021 at 6:54:38 PM UTC-6, gg...@yahoo.com wrote:

> But here is some hope, do you want your car to run ARM8 so every hacker on
> the planet can hack your car, or something different?

That's considered "security by obscurity", which isn't.

John Savard

On Friday, April 30, 2021 at 11:48:17 PM UTC-5, Quadibloc wrote:
> On Friday, April 30, 2021 at 6:54:38 PM UTC-6, gg...@yahoo.com wrote:
>
> > But here is some hope, do you want your car to run ARM8 so every hacker on
> > the planet can hack your car, or something different?
> That's considered "security by obscurity", which isn't.
<
Only 3 letter agencies believe in security through obscurity.
>
> John Savard

MitchAlsup [2021-05-01 07:48:30] wrote:
> On Friday, April 30, 2021 at 11:48:17 PM UTC-5, Quadibloc wrote:
>> On Friday, April 30, 2021 at 6:54:38 PM UTC-6, gg...@yahoo.com wrote:
>> > But here is some hope, do you want your car to run ARM8 so every hacker on
>> > the planet can hack your car, or something different?
>> That's considered "security by obscurity", which isn't.
> Only 3 letter agencies believe in security through obscurity.

To the extent that they only believe in it *for others*, I think they
are actually far from the only ones :-(

Stefan

On 2021-05-01, Quadibloc wrote:
> On Friday, April 30, 2021 at 6:54:38 PM UTC-6, gg...@yahoo.com wrote:
>
>> But here is some hope, do you want your car to run ARM8 so every hacker on
>> the planet can hack your car, or something different?
>
> That's considered "security by obscurity", which isn't.
>
> John Savard
>

Not sure that it's the same. Attack surfaces are attractive if enough
systems use them (or if there's a significant win). Having an uncommon
enough ISA, OS or system architecture will give you some level of
protection against the most common hacker attempts (for the hacker it's
a matter of effort vs outcome).

"Security by anomaly"? Still not a solid strategy though

/Marcus

Marcus wrote:
> On 2021-05-01, Quadibloc wrote:
>> On Friday, April 30, 2021 at 6:54:38 PM UTC-6, gg...@yahoo.com wrote:
>>
>>> But here is some hope, do you want your car to run ARM8 so every
>>> hacker on
>>> the planet can hack your car, or something different?
>>
>> That's considered "security by obscurity", which isn't.
>>
>> John Savard
>>
>
> Not sure that it's the same. Attack surfaces are attractive if enough
> systems use them (or if there's a significant win). Having an uncommon
> enough ISA, OS or system architecture will give you some level of
> protection against the most common hacker attempts (for the hacker it's
> a matter of effort vs outcome).
>
> "Security by anomaly"? Still not a solid strategy though

Stuxnet proved that with a suffiently interesting target, even a very
special cpu+api interface, plus air gap security, isn't enough to stop a
determined attacker.

Terje

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

> Not sure that it's the same. Attack surfaces are attractive if enough
> systems use them (or if there's a significant win). Having an uncommon
> enough ISA, OS or system architecture will give you some level of
> protection against the most common hacker attempts (for the hacker it's
> a matter of effort vs outcome).
>
> "Security by anomaly"? Still not a solid strategy though

I'd call it "security by natural selection", in the sense that you
gain some safety by virtue of the others being slightly easier targets.

Stefan

> Stuxnet proved that with a suffiently interesting target, even a very
> special cpu+api interface, plus air gap security, isn't enough to stop
> a determined attacker.

But if the attackers, while quite determined to attack someone, don't
care very much who they attack, running a somewhat unusual setup can be
enough.

Of course, nowadays many attacks don't care about the ISA, but if you
consider machine-language-level attacks, then maybe it could make sense
to use a kind of "randomized ISA" (along the same lines as ASLR).

I generally prefer language-based security, so I'd tend to presume that
implementing a "randomized ISA" feature wouldn't be worth the trouble,
but it's probably not much more complex than the kind of encrypted RAM
craziness that already exists.

Stefan

On Saturday, May 1, 2021 at 4:20:48 PM UTC-5, Stefan Monnier wrote:
> > Stuxnet proved that with a suffiently interesting target, even a very
> > special cpu+api interface, plus air gap security, isn't enough to stop
> > a determined attacker.
<
> But if the attackers, while quite determined to attack someone, don't
> care very much who they attack, running a somewhat unusual setup can be
> enough.
<
Attacks become much harder when only the address space of the user
is in the MMU. The sharing of the upper address space for the OS creates
a lot of opportunities for the attackers.
>
> Of course, nowadays many attacks don't care about the ISA, but if you
> consider machine-language-level attacks, then maybe it could make sense
> to use a kind of "randomized ISA" (along the same lines as ASLR).
<
Separating the address space of the JITer from the address space of
the JITed would do similar.
>
> I generally prefer language-based security, so I'd tend to presume that
> implementing a "randomized ISA" feature wouldn't be worth the trouble,
> but it's probably not much more complex than the kind of encrypted RAM
> craziness that already exists.
>
>
> Stefan

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Not sure that it's the same. Attack surfaces are attractive if enough
>> systems use them (or if there's a significant win). Having an uncommon
>> enough ISA, OS or system architecture will give you some level of
>> protection against the most common hacker attempts (for the hacker it's
>> a matter of effort vs outcome).
>>
>> "Security by anomaly"? Still not a solid strategy though
>
> I'd call it "security by natural selection", in the sense that you
> gain some safety by virtue of the others being slightly easier targets.

There is also a time delay for hacks to distribute which is 90% of the
benefit of running POWER. IBM will have patched most exploits before enough
time has passed for the exploit to be ported to POWER. Besides of course
three letter agencies which only bother hostile enemies while spying on
all. I expect that I am spied on and don’t care.

The creator of a new exploit will go mass market to make the most from that
exploit, POWER is not what you would target first, which means basically
never as most exploits would be patched before the port started.