Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

All extremists should be taken out and shot.


devel / comp.arch / Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

SubjectAuthor
* Upcoming DFP support in clang/LLVMIvan Godard
+* Re: Upcoming DFP support in clang/LLVMQuadibloc
|`* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| +* Re: Upcoming DFP support in clang/LLVMJohn Levine
| |+* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||`* Re: Upcoming DFP support in clang/LLVMJohn Levine
| || +- Re: Upcoming DFP support in clang/LLVMQuadibloc
| || `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||  `* Re: Upcoming DFP support in clang/LLVMBGB
| ||   `* Re: Upcoming DFP support in clang/LLVMJohn Dallman
| ||    `* Re: Upcoming DFP support in clang/LLVMBGB
| ||     +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |`* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     | `* Re: Upcoming DFP support in clang/LLVMTim Rentsch
| ||     |  +- Re: Upcoming DFP support in clang/LLVMMitchAlsup
| ||     |  `* Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| ||     |   `- Re: Upcoming DFP support in clang/LLVMBGB
| ||     `- Re: Upcoming DFP support in clang/LLVMJohn Dallman
| |+- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| |`* Re: Upcoming DFP support in clang/LLVMBGB
| | +- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `* Architecture comparison (was: Upcoming DFP support in clang/LLVM)Anton Ertl
| | | |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Bill Findlay
| | | |   |`* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   | `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |  `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |   +* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Ivan Godard
| | | |   |   |`- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |   |    +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |   |    `* Re: Architecture comparisonTerje Mathisen
| | | |   |     +- Re: Architecture comparisonBGB
| | | |   |     +* Re: Architecture comparisonThomas Koenig
| | | |   |     |`- Re: Architecture comparisonMitchAlsup
| | | |   |     `* Re: Architecture comparisonMichael S
| | | |   |      `* Re: Architecture comparisonMitchAlsup
| | | |   |       +- Re: Architecture comparisonBGB
| | | |   |       `- Re: Architecture comparisonMichael S
| | | |   `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)MitchAlsup
| | | |    `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Quadibloc
| | | |     `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |      `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |       `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Stephen Fuld
| | | |        `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)BGB
| | | |         +- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)John Dallman
| | | |         `* Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Robert Swindells
| | | |          `- Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)Torbjorn Lindgren
| | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | `- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | +* Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | | |`* Re: Upcoming DFP support in clang/LLVMBGB
| | | | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | | |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | | `* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  +* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | |  |+- Re: Upcoming DFP support in clang/LLVMQuadibloc
| | | |  |`- Re: Upcoming DFP support in clang/LLVMTerje Mathisen
| | | |  +- Re: Upcoming DFP support in clang/LLVMrobf...@gmail.com
| | | |  `- Re: Upcoming DFP support in clang/LLVMBGB
| | | +- Re: Graphics in the old days, wasUpcoming DFP support in clang/LLVMJohn Levine
| | | `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | +* Re: Upcoming DFP support in clang/LLVMQuadibloc
| | |`* Re: Upcoming DFP support in clang/LLVMBill Findlay
| | | +- Re: Upcoming DFP support in clang/LLVMIvan Godard
| | | `* Re: Upcoming DFP support in clang/LLVMBrian G. Lucas
| | |  `- Re: Upcoming DFP support in clang/LLVMBill Findlay
| | +- Re: Upcoming DFP support in clang/LLVMStephen Fuld
| | +* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |`* Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | | `* Re: Upcoming DFP support in clang/LLVMMitchAlsup
| | |  +* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMJohn Levine
| | |  |`* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  | `* Re: Fortran archaeology, Upcoming DFP support in clang/LLVMThomas Koenig
| | |  |  `- Re: Fortran archaeology, Upcoming DFP support in clang/LLVMMitchAlsup
| | |  `- Re: Upcoming DFP support in clang/LLVMThomas Koenig
| | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMaph
| |   |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   | `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |   |  |`* Re: tiny little computers, was Upcoming DFP support in clang/LLVMIvan Godard
| |   |  | `- Re: tiny little pages, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMBGB
| |   |  +* Re: tiny little computers, was Upcoming DFP support in clang/LLVMMitchAlsup
| |   |  |`- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   |  `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |   |   `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| |   +- Re: tiny little computers, was Upcoming DFP support in clang/LLVMRobert Swindells
| |   `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMEricP
| |    `* Re: tiny little computers, was Upcoming DFP support in clang/LLVMBill Findlay
| |     `- Re: tiny little computers, was Upcoming DFP support in clang/LLVMJohn Levine
| +- Re: Upcoming DFP support in clang/LLVMGuillaume
| `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
|  `* Re: Upcoming DFP support in clang/LLVMThomas Koenig
`* Re: Upcoming DFP support in clang/LLVMMichael S

Pages:12345
Re: Upcoming DFP support in clang/LLVM

<t5192u$1tg7$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25096&group=comp.arch#25096

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 21:38:06 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5192u$1tg7$1@gioia.aioe.org>
References: <t4qm5s$8rv$1@dont-email.me>
<memo.20220503192241.8344H@jgd.cix.co.uk> <t4s699$ra2$1@dont-email.me>
<9c5f44df-efca-4fb3-845e-b37589b7097fn@googlegroups.com>
<t50cpf$1tnk$1@gioia.aioe.org> <86r1583uqa.fsf@linuxsc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="62983"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.11.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Thu, 5 May 2022 19:38 UTC

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> MitchAlsup wrote:
>>
>>> When forced to use C++, I use the C subset.
>>
>> As I've stated before I tend to use C(+), where all the (+) features
>> have typically been included in more recent updates to the C standard.
>
> Can you be more specific? Presumably that includes many or
> most of the features introduced in C99. Do you know which
> ones (or which ones not)? Do you use any of the features
> introduced in C11 (or later?)?.

I'm not a language lawyer!

I just started using single-line comments and block-local variable
declarations back when this was allowed in C++ but not in C. There might
be some other stuff as well but nothing that specifically comes to mind.

Terje

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

Re: Upcoming DFP support in clang/LLVM

<t51ck9$gvs$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25097&group=comp.arch#25097

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Upcoming DFP support in clang/LLVM
Date: Thu, 5 May 2022 15:38:22 -0500
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <t51ck9$gvs$1@dont-email.me>
References: <t4qm5s$8rv$1@dont-email.me>
<memo.20220503192241.8344H@jgd.cix.co.uk> <t4s699$ra2$1@dont-email.me>
<9c5f44df-efca-4fb3-845e-b37589b7097fn@googlegroups.com>
<t50cpf$1tnk$1@gioia.aioe.org> <86r1583uqa.fsf@linuxsc.com>
<t5192u$1tg7$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 May 2022 20:38:33 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="91f2b55ce3b3229e84e8dd395e96bfa6";
logging-data="17404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/VDIH1A1+fYPMexz8Y523d"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:VlJ3JDLltZWNaQXtTWdTJNX8laU=
In-Reply-To: <t5192u$1tg7$1@gioia.aioe.org>
Content-Language: en-US
 by: BGB - Thu, 5 May 2022 20:38 UTC

On 5/5/2022 2:38 PM, Terje Mathisen wrote:
> Tim Rentsch wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> MitchAlsup wrote:
>>>
>>>> When forced to use C++, I use the C subset.
>>>
>>> As I've stated before I tend to use C(+), where all the (+) features
>>> have typically been included in more recent updates to the C standard.
>>
>> Can you be more specific?  Presumably that includes many or
>> most of the features introduced in C99.  Do you know which
>> ones (or which ones not)?  Do you use any of the features
>> introduced in C11 (or later?)?.
>
> I'm not a language lawyer!
>
> I just started using single-line comments and block-local variable
> declarations back when this was allowed in C++ but not in C. There might
> be some other stuff as well but nothing that specifically comes to mind.
>

My preferred style is mostly:
All declarations at top of function (like in C89);
Either /* ... */ or //
Usually /* ... */ for semantic / informational comments.
Usually // for commenting out code lines.
Will generally use "long long" and similar as-needed.

Though, this mostly lines up with the style that MSVC used until around
VS2013 or so.

Code which follows this style will also compile and run "pretty much
anywhere".

I vary some as to the reliance on things like pointer cast and
de-reference, as while "technically UB", these tend to work in most cases.

Likewise, most of the "approved" alternatives tend to fall into the
category of, "may work as expected, or perform like garbage, depending
on the compiler".

Though, tacking "volatile" onto the pointer is typically enough to get
the correct behavior on "offending" compilers (eg: GCC and Clang), while
also getting the expected performance on others, even if "still
technically UB".

BGBCC will parse a fair chunk of C99 and some amount of C11 and similar
as well (mostly cherry picking features from newer standards). Also, a
certain number of extensions.

Cases where I will deviate from my usual style are generally where this
is needed for performance reasons (and generally not where I intend code
to be portable).

Though, within the TestKern internals, this leads to some amount of
"this code will only build in BGBCC" situations.

Frequent offenders in this area are usually things like:
Using BJX2 inline ASM;
Assuming the existence of 128-bit integer types (*1);
Making use of various intrinsic functions;
...

*1: Like, even if they "aren't as good" as 32 or 64 bit integer types,
the performance of using the compiler-provided types seriously beats out
trying to fake them in C code.

Though, this also depends some on whether the program is built with ALUX
enabled (allows the compiler to make use of 128-bit ALU operations),
which are not considered part of the core ISA.

If not enabled, the compiler will deal with these types mostly via
runtime calls (mostly calling ASM blobs).

If enabled, basic operations on these types will be almost as fast as
the 64 bit integer types.

....

Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<2022May8.160036@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25127&group=comp.arch#25127

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 08 May 2022 14:00:36 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 67
Message-ID: <2022May8.160036@mips.complang.tuwien.ac.at>
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com> <t4sans$smp$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="6e4f0170b8a8cb5da03a1add0c771453";
logging-data="2357"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WfbWpovCSe3QC+lyEC5wb"
Cancel-Lock: sha1:KkKCP1AiWZ61f4Ho2wC3+BhKks8=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 8 May 2022 14:00 UTC

BGB <cr88192@gmail.com> writes:
>It looks like:
> PDP-11:
> 8x 16-bit
> Various addressing modes
> Looks kinda like an MSP430 with half as many registers;

Both have two-address instructions where both operands can be in memory.

> Also sorta resembles the M68K.

The M68k does not have general-purpose registers.
Apart from MOVE, all instructions have only one memory operand.

> VAX
> 16x 32-bit
> Kinda similar to PDP-11.

VAX has three-operand instructions, and all operands can be in memory.

>Contrast is x86, which appears to have emerged separately.
> I would probably cluster x86, Z80, and 6502 as another family.

The relationships are well-known:

6800 -> 6502
6800 -> 6809
6800 -> 68000

(all incompatible) These are all machines with accumulators and index
registers (accumulator machines), with the 6809 having more
accumulators (2x8-bit=1x16-bit) and more index registers (4x16-bit),
and the 68000 having 8x32-bit each. What was mostly kept is the one
memory operand per instruction.

8008->8080
8080->Z80
8080->8086
8086->IA-32
iA-32->AMD64

These started out with special-purpose registers (accumulator, index,
counter, address) but turned more and more general-purpose over time.
Again, one memory operand per instruction. Already in the 8086 the
general instructions could treat all registers as register operand,
and IA-32 finally had general-purpose registers (all registers could
also be used for addressing). AMD64 meant that byte operands could
reside in all registers.

>ARM32 seems to have some superficial similarities both to the PDP and
>x86,

Which ones?

>albeit initially built around 32-bit instruction words and
>Load/Store, putting it more in with other RISC family ISAs.
>
>Eg:
> 32-bit instruction words, often fixed-length;

A32 is fixed-length. Later T32 was added, which also allows 16-bit
instruction words (subset of same instruction set).

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

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t59b2e$nd2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25138&group=comp.arch#25138

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 8 May 2022 15:59:48 -0500
Organization: A noiseless patient Spider
Lines: 373
Message-ID: <t59b2e$nd2$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 8 May 2022 21:01:02 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="32c7f971df2624d31707ff8144820733";
logging-data="23970"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hSe0/2IOzImUHd1oVSn9i"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:IR480l4qB/PLpA4v+TZJfQJBsEI=
In-Reply-To: <2022May8.160036@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: BGB - Sun, 8 May 2022 20:59 UTC

On 5/8/2022 9:00 AM, Anton Ertl wrote:
> BGB <cr88192@gmail.com> writes:
>> It looks like:
>> PDP-11:
>> 8x 16-bit
>> Various addressing modes
>> Looks kinda like an MSP430 with half as many registers;
>
> Both have two-address instructions where both operands can be in memory.
>
>> Also sorta resembles the M68K.
>
> The M68k does not have general-purpose registers.
> Apart from MOVE, all instructions have only one memory operand.
>

Yeah, but similar-looking ASM, apart from splitting up the registers and
some other things.

All 3 ISA designs have in common that they are built around 16-bit
instruction words, often with a similar-ish layout, eg:
op,rn,mode,rm
Or:
op,mode,rn,mode,rm

>> VAX
>> 16x 32-bit
>> Kinda similar to PDP-11.
>
> VAX has three-operand instructions, and all operands can be in memory.
>

I was having a harder time finding as much information about VAX, so not
really sure what its encoding looks like.

From the "ASM and above" POV, it kinda resembles the others in this group.

>> Contrast is x86, which appears to have emerged separately.
>> I would probably cluster x86, Z80, and 6502 as another family.
>
> The relationships are well-known:
>
> 6800 -> 6502
> 6800 -> 6809
> 6800 -> 68000
>
> (all incompatible) These are all machines with accumulators and index
> registers (accumulator machines), with the 6809 having more
> accumulators (2x8-bit=1x16-bit) and more index registers (4x16-bit),
> and the 68000 having 8x32-bit each. What was mostly kept is the one
> memory operand per instruction.
>

Though, the 6502's design more resembles the 8080 and friends than it
does the M68K.

Looking, the 6800 and 68000 appear to be significantly different.
Though, yeah, there is some similarity between the 6800 and 6502 as well.

Could probably lump them together by common features:
Similar registers: Accumulator, Index, Stack, Program Counter
8-bit instructions
...

> 8008->8080
> 8080->Z80
> 8080->8086
> 8086->IA-32
> iA-32->AMD64
>
> These started out with special-purpose registers (accumulator, index,
> counter, address) but turned more and more general-purpose over time.
> Again, one memory operand per instruction. Already in the 8086 the
> general instructions could treat all registers as register operand,
> and IA-32 finally had general-purpose registers (all registers could
> also be used for addressing). AMD64 meant that byte operands could
> reside in all registers.
>

I consider the 8086 to be a pretty big jump from the 8080.

Despite both having a common ancestor in the 8080, for example, the 8086
and Z80 are quite different from each other.

>> ARM32 seems to have some superficial similarities both to the PDP and
>> x86,
>
> Which ones?
>

ARM32 has autoincrement modes, and scaled index addressing.
Autoincrement was mostly seen in the PDP inspired ISAs.
Scaled index was seen in the x86 and M68K.

ARM32 uses page-based virtual memory, with a page-table format that
appeared very similar to that of the 386.

I would need to look around more to figure out the timeline for when
each added these features in relation to each other.

>> albeit initially built around 32-bit instruction words and
>> Load/Store, putting it more in with other RISC family ISAs.
>>
>> Eg:
>> 32-bit instruction words, often fixed-length;
>
> A32 is fixed-length. Later T32 was added, which also allows 16-bit
> instruction words (subset of same instruction set).
>

I was not counting Thumb because it was apparently added much later
(90s), and was apparently inspired by the SuperH.

Though, compared with the SuperH, its instruction format was
significantly more bit-twiddly.

Well, at least until RISC-V came along and was like "hold my beer".

So, SuperH:
zzzz-nnnn-mmmm-zzzz //typical 2R op
zzzz-nnnn-zzzz-zzzz //typical 1R op
zzzz-nnnn-mmmm-iiii //a few Ld/St ops
zzzz-nnnn-iiii-iiii //a few immediate instructions.
zzzz-zzzz-iiii-iiii //a few other instructions.

Thumb shook it up some, tried fitting some 3-register forms in the mix
(with 3-bit registers).

Thumb layout was pretty variable, but at least, if bits were next to
each other, they were in the expected order.

RVC has stuff all over the place, and even in most cases where bits
"are" next to each other, they are not in a consistent order, and things
like which bits go where are prone to vary from one instruction form to
the next.

If one counts variations where the bits are in a different order, the
number of RVC instruction layouts is well into the double-digits.

This is partly why the RISC-V mode for the BJX2 core has not yet added
RVC support. I start trying to poke at it, and quickly lose my
motivation to deal with this level of bit-confetti...

It is possible I may just leave it at RV64IM levels for a while.
'C': "WTF is going on with their encodings?"
'A': Defines cache semantics which don't match my L1
'A' also diverges from strict Load/Store semantics.
As-specified, one would need to add an ALU to the L1 cache.
'F'/'D': Doesn't really match up with my existing FPU.
Supporting their FPU design would add considerable cost.
...

In terms of 16-bit ops, BJX2 has:
zzzz-zzzz-nnnn-mmmm //typical 2R ops
zzzz-nzzz-nnnn-zzzz //typical 1R ops
zzzz-ziii-nnnn-mmmm //A few LD/ST ops
zzzz-zznm-nnnn-mmmm //A few 2R ops (R0..R31)
zzzz-zzzz-nnnn-iiii //a few 2RI ops (Imm4)
zzzz-nnnn-iiii-iiii //a few immediate instructions (Imm8).
zzzz-zzzz-iiii-iiii //a few other instructions.

It is possible (in retrospect) it could have been better had BJX2 stayed
slightly closer to the original SH layout, but oh well.

However, the way 32-bit instruction formats had worked in SuperH (and
BJX1) had "sucked pretty hard" (they were all shoved into odd corners of
the 16-bit encoding space, so one would need to look at ~ 12 instruction
bits to distinguish between 16 and 32 bit encodings).

I had mostly managed to keep it consistent in BJX2, at least until I
added the XGPR extension (adds encodings for R32..R63), which kinda made
a mess of things in this area. Also adds a bit of penalty for things
like interrupt handling and task-switching as well (since they need to
be saved/restored).

So, a possibly "similar, but hopefully more consistent":
00zz-nnnn-mmmm-zzzz (16-bit, 2R)
01zz-nnnn-iiii-zzzz (16-bit, 2RI)
10zz-zzzz-iiii-iiii (16-bit, Imm8 and Misc)
11**-****-****-**** (32-bit)

For 32-bit encodings, possibly (5b regs)
11pp-pzzz-zzzn-nnnn zzss-sssz-zzzt-tttt //3R (Rs, Rt, Rn)
11pp-pzzz-zzzn-nnnn zzss-sssi-iiii-iiii //3RI (Rs, Imm9, Rn)
11pp-pzzz-zzzn-nnnn iiii-iiii-iiii-iiii //2RI (Imm16, Rn)
11pp-pzzz-zzzz-iiii iiii-iiii-iiii-iiii //(Imm20)
11pp-pzzz-iiii-iiii iiii-iiii-iiii-iiii //(Imm24 / Jumbo)

Or 32-bit encodings (6b regs)
11pp-pzzz-zznn-nnnn zsss-sssz-zztt-tttt //3R (Rs, Rt, Rn)
11pp-pzzz-zznn-nnnn zsss-sssi-iiii-iiii //3RI (Rs, Imm9, Rn)
11pp-pzzz-zznn-nnnn iiii-iiii-iiii-iiii //2RI (Imm16, Rn)
11pp-pzzz-zzzz-iiii iiii-iiii-iiii-iiii //(Imm20)
11pp-pzzz-iiii-iiii iiii-iiii-iiii-iiii //(Imm24 / Jumbo)

Would stick with Imm9 vs Imm12 as personally I feel Imm12 wastes too
much encoding space.

This layout also keeps Imm16 consistent with the other encodings (unlike
BJX2, where the Imm16 block uses a different/incompatible layout).

Where, ppp:
000: Op?T (Pred?T)
001: Op?F (Pred?F)
010: Op?T| (Pred?T + WEX, PrWEX)
011: Op?F| (Pred?F + WEX, PrWEX)
100: Op (Normal)
101: Special / Misc
110: Op| (WEX)
111: Jumbo

So, say:
1111-1zzz-iiii-iiii iiii-iiii-iiii-iiii (Jumbo-Prefix Instructions)
The 'zzz' field mostly defines how the prefix combines with next op.
000: Expand Immediate field by 24 bits
001: Expand the Opcode space and add 4th Reg/Imm field
...

This still allows 64-bit ops with Imm33s, or 96-bit ops with Imm64.
Having 96-bit encodings for "MOV Imm64, Rn" and "ADD Imm64, Rn" being
very often useful.

Would keep the Link Register hard-wired, as the costs of having a
flexible link register just "doesn't really seem worth it".

Choice between 5b and 6b regs is less obvious:
5b regs: Plenty sufficient for 95% of code
It is uncommon to find code where this is not sufficient
6b regs: Can pay off for that last 5% or so.
But, eats a lot of potential encoding space.
This would have less opcode space than in BJX2.
Or, make most of the ISA use 5b registers:
With only a subset having 6b registers;
Though, this doesn't really solve the issue.


Click here to read the complete article
Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<0001HW.28287BAE0057416370000574538F@news.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25140&group=comp.arch#25140

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: findlayb...@blueyonder.co.uk (Bill Findlay)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 08 May 2022 23:29:02 +0100
Organization: none
Lines: 11
Message-ID: <0001HW.28287BAE0057416370000574538F@news.individual.net>
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com> <97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com> <t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at> <t59b2e$nd2$1@dont-email.me>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 0u2y/bpY5kCYZLgecGkbZQJE+eGT0i1tQ4scygGKrrJToRgYXG
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:6E1xhbwg/kjehpaio7yN1nW33BM=
User-Agent: Hogwasher/5.24
 by: Bill Findlay - Sun, 8 May 2022 22:29 UTC

On 8 May 2022, BGB wrote
(in article <t59b2e$nd2$1@dont-email.me>):

> I was having a harder time finding as much information about VAX,
> so not really sure what its encoding looks like.

O tempora, o mores!
8-)
--
Bill Findlay

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25141&group=comp.arch#25141

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5f89:0:b0:45a:f6d9:41c1 with SMTP id jp9-20020ad45f89000000b0045af6d941c1mr7438203qvb.50.1652049701765;
Sun, 08 May 2022 15:41:41 -0700 (PDT)
X-Received: by 2002:aca:b782:0:b0:325:7a29:352d with SMTP id
h124-20020acab782000000b003257a29352dmr9374914oif.217.1652049701496; Sun, 08
May 2022 15:41:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.neodome.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 8 May 2022 15:41:41 -0700 (PDT)
In-Reply-To: <t59b2e$nd2$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:c058:497c:25c3:26c7;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:c058:497c:25c3:26c7
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at> <t59b2e$nd2$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 08 May 2022 22:41:41 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2873
 by: MitchAlsup - Sun, 8 May 2022 22:41 UTC

On Sunday, May 8, 2022 at 4:01:05 PM UTC-5, BGB wrote:
> On 5/8/2022 9:00 AM, Anton Ertl wrote:
--------------------------------------------------------------------------------------------------------------------------
> >> VAX
> >> 16x 32-bit
> >> Kinda similar to PDP-11.
> >
> > VAX has three-operand instructions, and all operands can be in memory.
> >
> I was having a harder time finding as much information about VAX, so not
> really sure what its encoding looks like.
<
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fusers.cs.jmu.edu%2Fabzugcx%2FPublic%2FStudent-Produced-Term-Projects%2FComputer-Organization-2004-SPRING%2FVAX-Architecture-by-William-French-Ahmed-Kareem-Horatiu-Stancu-Steve-Tran-2004-Spring.doc%3Fmsclkid%3Dcabff162cf1e11eca63151700b2ca4c0&wdOrigin=BROWSELINK
>
<snip>
> Could probably lump them together by common features:
> Similar registers: Accumulator, Index, Stack, Program Counter
> 8-bit instructions
> ...
> > 8008->8080
> > 8080->Z80
Why do people always forget about the 8085 ??
> > 8080->8086
> > 8086->IA-32
> > iA-32->AMD64

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t59i4h$bov$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25142&group=comp.arch#25142

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 8 May 2022 18:00:23 -0500
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <t59i4h$bov$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 8 May 2022 23:01:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f8c2b636d650391a1228a7ccd31f5f40";
logging-data="12063"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Vqk54/dLg0DAViatpE9Gd"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:fyrjFhC+ZJ3lo+4u7DAmsmbQnKo=
In-Reply-To: <0001HW.28287BAE0057416370000574538F@news.individual.net>
Content-Language: en-US
 by: BGB - Sun, 8 May 2022 23:00 UTC

On 5/8/2022 5:29 PM, Bill Findlay wrote:
> On 8 May 2022, BGB wrote
> (in article <t59b2e$nd2$1@dont-email.me>):
>
>> I was having a harder time finding as much information about VAX,
>> so not really sure what its encoding looks like.
>
> O tempora, o mores!
> 8-)

I have now found something (in the form of a scanned copy of an 80s era
ISA manual), it appears to be a variable-length byte-oriented encoding.

Most other stuff I had seen previously does not go below the level of
its ASM notation.

A quick skim implies it is structured like:
Opcode Operand*
With each operand encoded as a variable number of 1 or more bytes.

....

This design looks like something that would make more sense for an
interpreter than for a machine ISA.

Could maybe decode it using a state machine:
Read Opcode
Read each operand;
Do operation;
Store result.

But, errm, doing it this way, the performance would suck.

Could maybe have decoder support for a special case subset where
everything is located in registers. This would have no obvious advantage
over a RISC or VLIW style ISA though.

....

Started expanding out the other idea I had as another idea spec, not
sure if I will do anything with it though.

As usual, once one starts trying to spec things out, then the cracks in
the design start to show up...

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25143&group=comp.arch#25143

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:c29:b0:45a:fedd:7315 with SMTP id a9-20020a0562140c2900b0045afedd7315mr6031918qvd.59.1652055245293;
Sun, 08 May 2022 17:14:05 -0700 (PDT)
X-Received: by 2002:a05:6830:2aa1:b0:606:3a07:646b with SMTP id
s33-20020a0568302aa100b006063a07646bmr4905269otu.229.1652055245089; Sun, 08
May 2022 17:14:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 8 May 2022 17:14:04 -0700 (PDT)
In-Reply-To: <t59i4h$bov$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:c058:497c:25c3:26c7;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:c058:497c:25c3:26c7
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 09 May 2022 00:14:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 9 May 2022 00:14 UTC

On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
> On 5/8/2022 5:29 PM, Bill Findlay wrote:
> > On 8 May 2022, BGB wrote
> > (in article <t59b2e$nd2$1...@dont-email.me>):
> >
> >> I was having a harder time finding as much information about VAX,
> >> so not really sure what its encoding looks like.
> >
> > O tempora, o mores!
> > 8-)
> I have now found something (in the form of a scanned copy of an 80s era
> ISA manual), it appears to be a variable-length byte-oriented encoding.
>
> Most other stuff I had seen previously does not go below the level of
> its ASM notation.
>
>
> A quick skim implies it is structured like:
> Opcode Operand*
> With each operand encoded as a variable number of 1 or more bytes.
>
> ...
>
>
> This design looks like something that would make more sense for an
> interpreter than for a machine ISA.
<
Exactly what it was designed for:: except the interpreter was microcode.
>
> Could maybe decode it using a state machine:
> Read Opcode
> Read each operand;
> Do operation;
> Store result.
>
> But, errm, doing it this way, the performance would suck.
<
Compared to modern wide-issue machines yes.
Compared to its competitors of the day:: no -- a resounding NO
Its competitors were doing about 1 instruction every 4-6 clocks.
<
An argument VAX supported back then used was:: ½ of the operands
would be instructions in lesser ISAs.
>
>
> Could maybe have decoder support for a special case subset where
> everything is located in registers. This would have no obvious advantage
> over a RISC or VLIW style ISA though.
>
But no compiler and no assembler programmer used this ISA like that.
<
It took them most of a decade to figure out that JSR/RTS was faster than
CALLG/RET {why is a story for another time.....}

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t59rno$7rm$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25148&group=comp.arch#25148

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 8 May 2022 20:44:14 -0500
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <t59rno$7rm$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 9 May 2022 01:45:28 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f8c2b636d650391a1228a7ccd31f5f40";
logging-data="8054"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/JvbXToPXfYpZm2uhdCmfB"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:cP69igEZ5EhI1qPKK8LZ0Gye4VM=
In-Reply-To: <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
Content-Language: en-US
 by: BGB - Mon, 9 May 2022 01:44 UTC

On 5/8/2022 7:14 PM, MitchAlsup wrote:
> On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
>> On 5/8/2022 5:29 PM, Bill Findlay wrote:
>>> On 8 May 2022, BGB wrote
>>> (in article <t59b2e$nd2$1...@dont-email.me>):
>>>
>>>> I was having a harder time finding as much information about VAX,
>>>> so not really sure what its encoding looks like.
>>>
>>> O tempora, o mores!
>>> 8-)
>> I have now found something (in the form of a scanned copy of an 80s era
>> ISA manual), it appears to be a variable-length byte-oriented encoding.
>>
>> Most other stuff I had seen previously does not go below the level of
>> its ASM notation.
>>
>>
>> A quick skim implies it is structured like:
>> Opcode Operand*
>> With each operand encoded as a variable number of 1 or more bytes.
>>
>> ...
>>
>>
>> This design looks like something that would make more sense for an
>> interpreter than for a machine ISA.
> <
> Exactly what it was designed for:: except the interpreter was microcode.

Hmm...

I guess I can note that I had previously designed some 3R bytecode ISA's
along a vaguely similar line, but still didn't go quite as far as VAX
did in this direction.

It does also sorta remind me of EFI ByteCode, though after finding a
spec for it, EBC still appears to be a little more conservative than the
VAX.

Like, it looks like, on VAX potentially something like:
bar->x = foo->x + (*ptr++);

Could be encoded as a single instruction?...

>>
>> Could maybe decode it using a state machine:
>> Read Opcode
>> Read each operand;
>> Do operation;
>> Store result.
>>
>> But, errm, doing it this way, the performance would suck.
> <
> Compared to modern wide-issue machines yes.
> Compared to its competitors of the day:: no -- a resounding NO
> Its competitors were doing about 1 instruction every 4-6 clocks.
> <
> An argument VAX supported back then used was:: ½ of the operands
> would be instructions in lesser ISAs.

I was thinking vs a RISC running at one instruction per clock.

Albeit, in an instruction-for-instruction sense, I guess the ISA design
would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
(where a RISC style ISA tends to need to execute more instructions for a
similar amount of work, at least when using Dhrystone as the metric).

In many cases, a VAX instruction could do the work equivalent of
multiple RISC-style instructions, if someone could somehow get this
thing running at near (or above) one instruction per clock, it would be
potentially "rather formidable" (possibly more so when dealing with a
lot of memory operands).

Though, one would likely need to be able to do upwards of 2 memory loads
and 1 memory store per cycle to be able to pull this off (wouldn't
likely be plausible with a single memory port).

Tasks like efficiently figuring out instruction length (for a pipelined
deccoder) would likely also be an issue. Will assume probably no
superscalar on this thing.

>>
>>
>> Could maybe have decoder support for a special case subset where
>> everything is located in registers. This would have no obvious advantage
>> over a RISC or VLIW style ISA though.
>>
> But no compiler and no assembler programmer used this ISA like that.
> <
> It took them most of a decade to figure out that JSR/RTS was faster than
> CALLG/RET {why is a story for another time.....}

Possibly true.

Still haven't looked at the ISA in much detail.

I will guess things like expecting the compiler to unroll loops and
modulo schedule stuff, or expecting the compiler to shuffle instructions
to minimize interlock stalls, ..., wasn't really a thing yet.

....

My own effort has ended up going in the direction of switching the Boot
ROM over to dealing with text glyphs itself (via drawing it from a
14-segment representation), mostly so I could eliminate the cost of
having a hardware font ROM (which was at this point only still being
used by the Boot ROM).

The 14-segment text-rendering has lower readability than the more
traditional 8x8 pixel font though (but needs less ROM space than
required for an 8x8 pixel font, despite the added cost of the code
needed to "unpack" the blocks from 14-segment form into 8x8 pixel form
in order to be drawn into VRAM, *).

OTOH, in an "actual boot", most cases this font would only be in effect
for a fraction of a second so its lackluster readability doesn't really
matter all that much.

*: Though, the relative cost of the code for the 14-segment unpacking
logic does eat much of the ROM-space savings over just storing an 8x8
pixel font directly.

....

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t59t3l$ev8$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25150&group=comp.arch#25150

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Sun, 8 May 2022 19:08:53 -0700
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <t59t3l$ev8$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 9 May 2022 02:08:54 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b6e1250913471c33c07fa5515aa695d5";
logging-data="15336"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19i5MY4keK/upEosSUBXiGA"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:YrSqgWvq9KV3K73mCn0hXuWBgco=
In-Reply-To: <t59rno$7rm$1@dont-email.me>
Content-Language: en-US
 by: Ivan Godard - Mon, 9 May 2022 02:08 UTC

On 5/8/2022 6:44 PM, BGB wrote:
> On 5/8/2022 7:14 PM, MitchAlsup wrote:
>> On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
>>> On 5/8/2022 5:29 PM, Bill Findlay wrote:
>>>> On 8 May 2022, BGB wrote
>>>> (in article <t59b2e$nd2$1...@dont-email.me>):
>>>>
>>>>> I was having a harder time finding as much information about VAX,
>>>>> so not really sure what its encoding looks like.
>>>>
>>>> O tempora, o mores!
>>>> 8-)
>>> I have now found something (in the form of a scanned copy of an 80s era
>>> ISA manual), it appears to be a variable-length byte-oriented encoding.
>>>
>>> Most other stuff I had seen previously does not go below the level of
>>> its ASM notation.
>>>
>>>
>>> A quick skim implies it is structured like:
>>> Opcode Operand*
>>> With each operand encoded as a variable number of 1 or more bytes.
>>>
>>> ...
>>>
>>>
>>> This design looks like something that would make more sense for an
>>> interpreter than for a machine ISA.
>> <
>> Exactly what it was designed for:: except the interpreter was microcode.
>
> Hmm...
>
> I guess I can note that I had previously designed some 3R bytecode ISA's
> along a vaguely similar line, but still didn't go quite as far as VAX
> did in this direction.
>
> It does also sorta remind me of EFI ByteCode, though after finding a
> spec for it, EBC still appears to be a little more conservative than the
> VAX.
>
>
> Like, it looks like, on VAX potentially something like:
>   bar->x = foo->x + (*ptr++);
>
> Could be encoded as a single instruction?...

Yes. But then, what's an instruction?

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25151&group=comp.arch#25151

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:15d1:b0:2f3:4dad:9f4 with SMTP id d17-20020a05622a15d100b002f34dad09f4mr13103879qty.287.1652062213456;
Sun, 08 May 2022 19:10:13 -0700 (PDT)
X-Received: by 2002:a05:6808:11ca:b0:2d9:a01a:488b with SMTP id
p10-20020a05680811ca00b002d9a01a488bmr10315784oiv.214.1652062213238; Sun, 08
May 2022 19:10:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 8 May 2022 19:10:13 -0700 (PDT)
In-Reply-To: <t59rno$7rm$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:c058:497c:25c3:26c7;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:c058:497c:25c3:26c7
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 09 May 2022 02:10:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 9 May 2022 02:10 UTC

On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
> On 5/8/2022 7:14 PM, MitchAlsup wrote:
> > On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
> >> On 5/8/2022 5:29 PM, Bill Findlay wrote:
> >>> On 8 May 2022, BGB wrote
> >>> (in article <t59b2e$nd2$1...@dont-email.me>):
> >>>
> >>>> I was having a harder time finding as much information about VAX,
> >>>> so not really sure what its encoding looks like.
> >>>
> >>> O tempora, o mores!
> >>> 8-)
> >> I have now found something (in the form of a scanned copy of an 80s era
> >> ISA manual), it appears to be a variable-length byte-oriented encoding..
> >>
> >> Most other stuff I had seen previously does not go below the level of
> >> its ASM notation.
> >>
> >>
> >> A quick skim implies it is structured like:
> >> Opcode Operand*
> >> With each operand encoded as a variable number of 1 or more bytes.
> >>
> >> ...
> >>
> >>
> >> This design looks like something that would make more sense for an
> >> interpreter than for a machine ISA.
> > <
> > Exactly what it was designed for:: except the interpreter was microcode..
> Hmm...
>
> I guess I can note that I had previously designed some 3R bytecode ISA's
> along a vaguely similar line, but still didn't go quite as far as VAX
> did in this direction.
>
> It does also sorta remind me of EFI ByteCode, though after finding a
> spec for it, EBC still appears to be a little more conservative than the
> VAX.
>
>
> Like, it looks like, on VAX potentially something like:
> bar->x = foo->x + (*ptr++);
<
!!! EVEN without having 'bar' or 'foo' in registers !!!
>
> Could be encoded as a single instruction?...
> >>
> >> Could maybe decode it using a state machine:
> >> Read Opcode
> >> Read each operand;
> >> Do operation;
> >> Store result.
> >>
> >> But, errm, doing it this way, the performance would suck.
> > <
> > Compared to modern wide-issue machines yes.
> > Compared to its competitors of the day:: no -- a resounding NO
> > Its competitors were doing about 1 instruction every 4-6 clocks.
> > <
> > An argument VAX supported back then used was:: ½ of the operands
> > would be instructions in lesser ISAs.
<
> I was thinking vs a RISC running at one instruction per clock.
>
>
> Albeit, in an instruction-for-instruction sense, I guess the ISA design
> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
> (where a RISC style ISA tends to need to execute more instructions for a
> similar amount of work, at least when using Dhrystone as the metric).
<
This is a question about how one defines work.
Floating point people do not count loads and stores--just FLOPs.
>
>
> In many cases, a VAX instruction could do the work equivalent of
> multiple RISC-style instructions, if someone could somehow get this
> thing running at near (or above) one instruction per clock, it would be
> potentially "rather formidable" (possibly more so when dealing with a
> lot of memory operands).
<
There are ways (now) of making VAX run above 1 instruction per cycle.
There are not CHEAP ways of making VAX run above 1 I/C.
>
> Though, one would likely need to be able to do upwards of 2 memory loads
> and 1 memory store per cycle to be able to pull this off (wouldn't
> likely be plausible with a single memory port).
<
You build a multiport temporal cache and run operands through it:: one side
calling it memory, the other side calling it registers.
>
>
> Tasks like efficiently figuring out instruction length (for a pipelined
> deccoder) would likely also be an issue. Will assume probably no
> superscalar on this thing.
<
Operand processing was only one of VAX's problems--a solvable one.
The things they put in the instruction set were worse::
CALLG/RET
EDIT
POLY
were significantly worse. There was even one instruction (/780) which
would thrash forever if you used all of the indirection address modes
simultaneously--the TLB was not big enough to handle the number of
PTEs required. {I might be off by 1 here}. But think about the situation
where a single instruction erased all latent information in the TLB !!
> >>
> >>
> >> Could maybe have decoder support for a special case subset where
> >> everything is located in registers. This would have no obvious advantage
> >> over a RISC or VLIW style ISA though.
> >>
> > But no compiler and no assembler programmer used this ISA like that.
> > <
> > It took them most of a decade to figure out that JSR/RTS was faster than
> > CALLG/RET {why is a story for another time.....}
> Possibly true.
>
> Still haven't looked at the ISA in much detail.
>
> I will guess things like expecting the compiler to unroll loops and
> modulo schedule stuff, or expecting the compiler to shuffle instructions
> to minimize interlock stalls, ..., wasn't really a thing yet.
<
VAX ISA was designed to encode as much work in as few bytes as practicable.
But somehow, they left out vectors and loops.
>
> ...
>
>
>
> My own effort has ended up going in the direction of switching the Boot
> ROM over to dealing with text glyphs itself (via drawing it from a
> 14-segment representation), mostly so I could eliminate the cost of
> having a hardware font ROM (which was at this point only still being
> used by the Boot ROM).
<
In my own effort, I intend to make ROM at least as fast as DRAM and
possible as fast as L3 cache--with certain enhancements. For example:
a single instruction can move a page of memory to another page of
memory. 1 instruction, 1 "bus" payload, appearing atomically to all
interested parties, and no damage to any of the intervening caches
and 1 unit of coherence traffic.
>
> The 14-segment text-rendering has lower readability than the more
> traditional 8x8 pixel font though (but needs less ROM space than
> required for an 8x8 pixel font, despite the added cost of the code
> needed to "unpack" the blocks from 14-segment form into 8x8 pixel form
> in order to be drawn into VRAM, *).
>
> OTOH, in an "actual boot", most cases this font would only be in effect
> for a fraction of a second so its lackluster readability doesn't really
> matter all that much.
<
I want to make the BIOS part of ROM useable to the kernel.
>
> *: Though, the relative cost of the code for the 14-segment unpacking
> logic does eat much of the ROM-space savings over just storing an 8x8
> pixel font directly.
>
> ...

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<db87154c-f5be-4b9f-84dc-7c21f92db937n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25152&group=comp.arch#25152

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:b742:0:b0:6a0:5e42:2fa8 with SMTP id h63-20020a37b742000000b006a05e422fa8mr5494890qkf.274.1652062281580;
Sun, 08 May 2022 19:11:21 -0700 (PDT)
X-Received: by 2002:a05:6808:6d7:b0:325:67ff:a21b with SMTP id
m23-20020a05680806d700b0032567ffa21bmr6396241oih.105.1652062281344; Sun, 08
May 2022 19:11:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 8 May 2022 19:11:21 -0700 (PDT)
In-Reply-To: <t59t3l$ev8$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:c058:497c:25c3:26c7;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:c058:497c:25c3:26c7
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me> <t59t3l$ev8$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <db87154c-f5be-4b9f-84dc-7c21f92db937n@googlegroups.com>
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 09 May 2022 02:11:21 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 9 May 2022 02:11 UTC

On Sunday, May 8, 2022 at 9:08:57 PM UTC-5, Ivan Godard wrote:
> On 5/8/2022 6:44 PM, BGB wrote:
> > On 5/8/2022 7:14 PM, MitchAlsup wrote:
> >> On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
> >>> On 5/8/2022 5:29 PM, Bill Findlay wrote:
> >>>> On 8 May 2022, BGB wrote
> >>>> (in article <t59b2e$nd2$1...@dont-email.me>):
> >>>>
> >>>>> I was having a harder time finding as much information about VAX,
> >>>>> so not really sure what its encoding looks like.
> >>>>
> >>>> O tempora, o mores!
> >>>> 8-)
> >>> I have now found something (in the form of a scanned copy of an 80s era
> >>> ISA manual), it appears to be a variable-length byte-oriented encoding.
> >>>
> >>> Most other stuff I had seen previously does not go below the level of
> >>> its ASM notation.
> >>>
> >>>
> >>> A quick skim implies it is structured like:
> >>> Opcode Operand*
> >>> With each operand encoded as a variable number of 1 or more bytes.
> >>>
> >>> ...
> >>>
> >>>
> >>> This design looks like something that would make more sense for an
> >>> interpreter than for a machine ISA.
> >> <
> >> Exactly what it was designed for:: except the interpreter was microcode.
> >
> > Hmm...
> >
> > I guess I can note that I had previously designed some 3R bytecode ISA's
> > along a vaguely similar line, but still didn't go quite as far as VAX
> > did in this direction.
> >
> > It does also sorta remind me of EFI ByteCode, though after finding a
> > spec for it, EBC still appears to be a little more conservative than the
> > VAX.
> >
> >
> > Like, it looks like, on VAX potentially something like:
> > bar->x = foo->x + (*ptr++);
> >
> > Could be encoded as a single instruction?...
> Yes. But then, what's an instruction?
<
Some think an instruction can contain cause than one state change.
{But this all get murky when you add in HW tablewalked TLBs.}

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t5ae8v$gau$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25155&group=comp.arch#25155

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Mon, 9 May 2022 02:00:38 -0500
Organization: A noiseless patient Spider
Lines: 346
Message-ID: <t5ae8v$gau$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 9 May 2022 07:01:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f8c2b636d650391a1228a7ccd31f5f40";
logging-data="16734"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Y60tXtJvVscIdoqYZCjEh"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:5DYnbNly8KtWns/E+js841iYxPc=
In-Reply-To: <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
Content-Language: en-US
 by: BGB - Mon, 9 May 2022 07:00 UTC

On 5/8/2022 9:10 PM, MitchAlsup wrote:
> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
>> On 5/8/2022 7:14 PM, MitchAlsup wrote:
>>> On Sunday, May 8, 2022 at 6:01:40 PM UTC-5, BGB wrote:
>>>> On 5/8/2022 5:29 PM, Bill Findlay wrote:
>>>>> On 8 May 2022, BGB wrote
>>>>> (in article <t59b2e$nd2$1...@dont-email.me>):
>>>>>
>>>>>> I was having a harder time finding as much information about VAX,
>>>>>> so not really sure what its encoding looks like.
>>>>>
>>>>> O tempora, o mores!
>>>>> 8-)
>>>> I have now found something (in the form of a scanned copy of an 80s era
>>>> ISA manual), it appears to be a variable-length byte-oriented encoding.
>>>>
>>>> Most other stuff I had seen previously does not go below the level of
>>>> its ASM notation.
>>>>
>>>>
>>>> A quick skim implies it is structured like:
>>>> Opcode Operand*
>>>> With each operand encoded as a variable number of 1 or more bytes.
>>>>
>>>> ...
>>>>
>>>>
>>>> This design looks like something that would make more sense for an
>>>> interpreter than for a machine ISA.
>>> <
>>> Exactly what it was designed for:: except the interpreter was microcode.
>> Hmm...
>>
>> I guess I can note that I had previously designed some 3R bytecode ISA's
>> along a vaguely similar line, but still didn't go quite as far as VAX
>> did in this direction.
>>
>> It does also sorta remind me of EFI ByteCode, though after finding a
>> spec for it, EBC still appears to be a little more conservative than the
>> VAX.
>>
>>
>> Like, it looks like, on VAX potentially something like:
>> bar->x = foo->x + (*ptr++);
> <
> !!! EVEN without having 'bar' or 'foo' in registers !!!
>>
>> Could be encoded as a single instruction?...
>>>>
>>>> Could maybe decode it using a state machine:
>>>> Read Opcode
>>>> Read each operand;
>>>> Do operation;
>>>> Store result.
>>>>
>>>> But, errm, doing it this way, the performance would suck.
>>> <
>>> Compared to modern wide-issue machines yes.
>>> Compared to its competitors of the day:: no -- a resounding NO
>>> Its competitors were doing about 1 instruction every 4-6 clocks.
>>> <
>>> An argument VAX supported back then used was:: ½ of the operands
>>> would be instructions in lesser ISAs.
> <
>> I was thinking vs a RISC running at one instruction per clock.
>>
>>
>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
>> (where a RISC style ISA tends to need to execute more instructions for a
>> similar amount of work, at least when using Dhrystone as the metric).
> <
> This is a question about how one defines work.
> Floating point people do not count loads and stores--just FLOPs.

I was thinking in the DMIPS sense.

Say, one has a core which is running:
39M bundles/sec, at ~ 1.3 instructions per bundle;
But, still only gets ~ 0.9 DMIPS/MHz...

Having briefly looked at VAX, it makes a little more sense.

Ability to run 1M of *these* instructions per second was more significant.

Having previously imagined the VAX as "basically like the PDP-11 but
32-bit and with more registers" made me think something was "kinda
broken" in my case.

Though, still doesn't really match SweRV in terms of DMIPS/MHz, but it
seems to be a very different design for the pipeline and L1 cache.

Though, I guess as a possible consolation prize, I can run my core at a
higher clock speed than SweRV at least...

>>
>>
>> In many cases, a VAX instruction could do the work equivalent of
>> multiple RISC-style instructions, if someone could somehow get this
>> thing running at near (or above) one instruction per clock, it would be
>> potentially "rather formidable" (possibly more so when dealing with a
>> lot of memory operands).
> <
> There are ways (now) of making VAX run above 1 instruction per cycle.
> There are not CHEAP ways of making VAX run above 1 I/C.

Possibly so.

>>
>> Though, one would likely need to be able to do upwards of 2 memory loads
>> and 1 memory store per cycle to be able to pull this off (wouldn't
>> likely be plausible with a single memory port).
> <
> You build a multiport temporal cache and run operands through it:: one side
> calling it memory, the other side calling it registers.

Possibly.

If one limits things to word-aligned memory access, and allow
address-keyed pipeline stages, it is possible that the L1 D$ could
operate similar to, or be treated an extension of, the register file.

There would likely be a "choke point" though, where the memory words
being used as instruction operands narrow down to interface with
external memory (say, the memory-registers may "miss" and need to be
saved/loaded to external RAM).

It is possible that one would also need a way to flush the offending
machine words to external RAM in the case of misaligned access (not
actually sure if VAX allows misaligned access though).

>>
>>
>> Tasks like efficiently figuring out instruction length (for a pipelined
>> deccoder) would likely also be an issue. Will assume probably no
>> superscalar on this thing.
> <
> Operand processing was only one of VAX's problems--a solvable one.
> The things they put in the instruction set were worse::
> CALLG/RET
> EDIT
> POLY
> were significantly worse. There was even one instruction (/780) which
> would thrash forever if you used all of the indirection address modes
> simultaneously--the TLB was not big enough to handle the number of
> PTEs required. {I might be off by 1 here}. But think about the situation
> where a single instruction erased all latent information in the TLB !!

Yeah. This is a concern with the reduced (2-way) associativity of XMOV
mode in my case.

If the I$ and D$ manage to land on the same index in the TLB, there is
barely enough associativity. If there was a potential for both A and B
to land on the same TLB index, while also missing on the other cache,
this happening was basically inevitable (and was prone to "actually
happen" in my tests in this area).

The workaround was to use a naive modulo scheme, which makes both A and
B landing on the same TLB index effectively impossible.

This issue seemingly also sets 2-way as the minimum TLB associativity
(at least, assuming one doesn't want the core to get stuck in an endless
TLB miss loop). Or, 4-way if using hashed indices.

>>>>
>>>>
>>>> Could maybe have decoder support for a special case subset where
>>>> everything is located in registers. This would have no obvious advantage
>>>> over a RISC or VLIW style ISA though.
>>>>
>>> But no compiler and no assembler programmer used this ISA like that.
>>> <
>>> It took them most of a decade to figure out that JSR/RTS was faster than
>>> CALLG/RET {why is a story for another time.....}
>> Possibly true.
>>
>> Still haven't looked at the ISA in much detail.
>>
>> I will guess things like expecting the compiler to unroll loops and
>> modulo schedule stuff, or expecting the compiler to shuffle instructions
>> to minimize interlock stalls, ..., wasn't really a thing yet.
> <
> VAX ISA was designed to encode as much work in as few bytes as practicable.
> But somehow, they left out vectors and loops.

Possibly so.
One could try to imagine an ISA that could express vector-processing
loops in a single big instruction.

>>
>> ...
>>
>>
>>
>> My own effort has ended up going in the direction of switching the Boot
>> ROM over to dealing with text glyphs itself (via drawing it from a
>> 14-segment representation), mostly so I could eliminate the cost of
>> having a hardware font ROM (which was at this point only still being
>> used by the Boot ROM).
> <
> In my own effort, I intend to make ROM at least as fast as DRAM and
> possible as fast as L3 cache--with certain enhancements. For example:
> a single instruction can move a page of memory to another page of
> memory. 1 instruction, 1 "bus" payload, appearing atomically to all
> interested parties, and no damage to any of the intervening caches
> and 1 unit of coherence traffic.


Click here to read the complete article
Re: Architecture comparison

<t5afsu$1kd5$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25156&group=comp.arch#25156

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!10O9MudpjwoXIahOJRbDvA.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Architecture comparison
Date: Mon, 9 May 2022 09:29:38 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5afsu$1kd5$1@gioia.aioe.org>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="53669"; posting-host="10O9MudpjwoXIahOJRbDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 9 May 2022 07:29 UTC

MitchAlsup wrote:
> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
>> (where a RISC style ISA tends to need to execute more instructions for a
>> similar amount of work, at least when using Dhrystone as the metric).
> <
> This is a question about how one defines work.
> Floating point people do not count loads and stores--just FLOPs.

This is particularly galling when we consider how the relative costs of
memory access vs FPU operations have changed:

I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
RAM, vs less than 10 pJ for an FMUL.

I.e. the loads are more than two orders of magnitude more expensive than
the FLOPs!

Terje

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

Re: Architecture comparison

<t5aktq$j2o$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25157&group=comp.arch#25157

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison
Date: Mon, 9 May 2022 03:54:08 -0500
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <t5aktq$j2o$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 9 May 2022 08:55:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f8c2b636d650391a1228a7ccd31f5f40";
logging-data="19544"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/wpF2NUJ6aeQ+Qk6n7s/bA"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:CV/R1OorPS1RpsikfkcSFQVFq+I=
In-Reply-To: <t5afsu$1kd5$1@gioia.aioe.org>
Content-Language: en-US
 by: BGB - Mon, 9 May 2022 08:54 UTC

On 5/9/2022 2:29 AM, Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
>>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
>>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
>>> (where a RISC style ISA tends to need to execute more instructions for a
>>> similar amount of work, at least when using Dhrystone as the metric).
>> <
>> This is a question about how one defines work.
>> Floating point people do not count loads and stores--just FLOPs.
>
> This is particularly galling when we consider how the relative costs of
> memory access vs FPU operations have changed:
>
> I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> RAM, vs less than 10 pJ for an FMUL.
>
> I.e. the loads are more than two orders of magnitude more expensive than
> the FLOPs!
>

Probably...

Say, BJX2 core executing 4x Binary32 SIMD ops, So 4 FLOPs in 10 cycles.

So, could theoretically pull off 20 MFLOP at 50MHz if doing it all with
FP-SIMD ops.

Now, say, it is in DRAM and operating on one big array and putting the
result in another big array, fastest case is ~ memcpy, or ~ 25 MB/s.

This is ~ 6M floats/sec for memcpy (1.6M vectors/sec, or around 31 clock
cycles average).

If we assume that we are adding two arrays of vectors, it jumps to
around 50 cycles for the load/store part, plus 10 cycles per vector for
the SIMD op.

So, ~ 3 MFLOP, if one counts DRAM transfers.
83% due to memory transfers;
17% due to the operation itself.

Then again, one could ask "who would be operating on large arrays of
floating point values in memory?..."

But, then I can note:
Quake spends more of its clock-cycles on waiting for cache misses than
it spends on doing anything else... (It is actually "almost playable" at
50MHz in the emulator, if one tells the emulator to disable modeling the
cache hierarchy).

Would it be playable if the core could do things OoO instead of stalling
the pipeline on each cache miss?... Maybe.

This also reminds me of people who go on about how much faster modern
CPUs are than older ones, and then give numbers that are basically so
large as to be almost entirely disconnected from reality (*), or what
one could get from "actually benchmarking stuff".

(*): Or they are based on numbers given for marketing fluff, which are
themselves sometimes suspect. Eg: Seeing recently some talk of a newer
Flash storage module intended for cell-phones, and someone listing its
IO bandwidth as "30 GB/sec" or similar, which is the sort of number I
would regard with a certain degree of skepticism.

I guess it possibly falls in a similar category of where I could claim
my BJX2 cores' ringbus can move 800 MB/s at 50MHz (eg: 16B every clock
cycle).

Nevermind if nothing would get anywhere near these sorts of IO speeds in
practice (eg: given things like request/response latency between the L1
cache and L2 cache, and that responses to requests need to arrive before
the CPU can continue working), ...

So, in practice we get closer to 67 MB/s (for a memcpy), with, say, 76%
of the clock-cycles (during the L2 memcpy) mostly just holding NOP
messages...

But, if there were marketing people in my case, they would probably much
rather claim 800MB/s than 67MB/s ...

> Terje
>

Re: Architecture comparison

<t5cvir$9do$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25163&group=comp.arch#25163

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd6-ee5-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Architecture comparison
Date: Tue, 10 May 2022 06:09:31 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t5cvir$9do$1@newsreader4.netcologne.de>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org>
Injection-Date: Tue, 10 May 2022 06:09:31 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd6-ee5-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd6:ee5:0:7285:c2ff:fe6c:992d";
logging-data="9656"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 10 May 2022 06:09 UTC

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> MitchAlsup wrote:
>> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
>>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
>>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
>>> (where a RISC style ISA tends to need to execute more instructions for a
>>> similar amount of work, at least when using Dhrystone as the metric).
>> <
>> This is a question about how one defines work.
>> Floating point people do not count loads and stores--just FLOPs.
>
> This is particularly galling when we consider how the relative costs of
> memory access vs FPU operations have changed:
>
> I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> RAM, vs less than 10 pJ for an FMUL.

Interesting figure.

Looking at the 94 GB per second with four memory channels
with DDR 2933 cited in

https://www.intel.com/content/www/us/en/support/articles/000056722/processors/intel-core-processors.html

gives you about 12 W of power for the memory subsystem at full
speed.

> I.e. the loads are more than two orders of magnitude more expensive than
> the FLOPs!

I suppose that routing the data back and forth also uses a lot
of power. I could not understand the thermal problems of AVX512
otherwise.

Re: Architecture comparison

<ad5b77fb-9bff-4b5d-9b1f-1517e3b25d80n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25171&group=comp.arch#25171

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:989:b0:69f:c506:2ac1 with SMTP id x9-20020a05620a098900b0069fc5062ac1mr15893253qkx.645.1652201602180;
Tue, 10 May 2022 09:53:22 -0700 (PDT)
X-Received: by 2002:a05:6870:3047:b0:ec:44c2:1718 with SMTP id
u7-20020a056870304700b000ec44c21718mr590417oau.214.1652201601895; Tue, 10 May
2022 09:53:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 10 May 2022 09:53:21 -0700 (PDT)
In-Reply-To: <t5cvir$9do$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:dc2e:8c1f:457a:8c1c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:dc2e:8c1f:457a:8c1c
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me> <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org> <t5cvir$9do$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ad5b77fb-9bff-4b5d-9b1f-1517e3b25d80n@googlegroups.com>
Subject: Re: Architecture comparison
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 10 May 2022 16:53:22 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Tue, 10 May 2022 16:53 UTC

On Tuesday, May 10, 2022 at 1:09:34 AM UTC-5, Thomas Koenig wrote:
> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> > MitchAlsup wrote:
> >> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
> >>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
> >>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
> >>> (where a RISC style ISA tends to need to execute more instructions for a
> >>> similar amount of work, at least when using Dhrystone as the metric).
> >> <
> >> This is a question about how one defines work.
> >> Floating point people do not count loads and stores--just FLOPs.
> >
> > This is particularly galling when we consider how the relative costs of
> > memory access vs FPU operations have changed:
> >
> > I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> > RAM, vs less than 10 pJ for an FMUL.
> Interesting figure.
>
> Looking at the 94 GB per second with four memory channels
> with DDR 2933 cited in
>
> https://www.intel.com/content/www/us/en/support/articles/000056722/processors/intel-core-processors.html
>
> gives you about 12 W of power for the memory subsystem at full
> speed.
> > I.e. the loads are more than two orders of magnitude more expensive than
> > the FLOPs!
> I suppose that routing the data back and forth also uses a lot
> of power. I could not understand the thermal problems of AVX512
> otherwise.
<
In your typical integer data path, the flip-flops (and clock driving them) consume
more power than the calculations (excepting MUL and DIV).

Re: Architecture comparison

<3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25178&group=comp.arch#25178

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:4488:b0:6a0:2aab:a736 with SMTP id x8-20020a05620a448800b006a02aaba736mr17212489qkp.717.1652210434982;
Tue, 10 May 2022 12:20:34 -0700 (PDT)
X-Received: by 2002:a05:6870:3047:b0:ec:44c2:1718 with SMTP id
u7-20020a056870304700b000ec44c21718mr960513oau.214.1652210434759; Tue, 10 May
2022 12:20:34 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 10 May 2022 12:20:34 -0700 (PDT)
In-Reply-To: <t5afsu$1kd5$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2a0d:6fc2:55b0:ca00:65dd:bb7:48b5:b678;
posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 2a0d:6fc2:55b0:ca00:65dd:bb7:48b5:b678
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me> <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>
Subject: Re: Architecture comparison
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 10 May 2022 19:20:34 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3183
 by: Michael S - Tue, 10 May 2022 19:20 UTC

On Monday, May 9, 2022 at 10:29:40 AM UTC+3, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
> >> Albeit, in an instruction-for-instruction sense, I guess the ISA design
> >> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
> >> (where a RISC style ISA tends to need to execute more instructions for a
> >> similar amount of work, at least when using Dhrystone as the metric).
> > <
> > This is a question about how one defines work.
> > Floating point people do not count loads and stores--just FLOPs.
> This is particularly galling when we consider how the relative costs of
> memory access vs FPU operations have changed:
>
> I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> RAM, vs less than 10 pJ for an FMUL.
>
> I.e. the loads are more than two orders of magnitude more expensive than
> the FLOPs!
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

The current Green500 champion (custom ASIC) delivers 39.379 GFlops/watts
== 25.4 pJ/FLOP ~= 50 pJ/FMADD
The best GPGPU is not far behind at 33.983 GFlops/watts
The best CPU is further down at 16.876 GFlops/watts. Only 2 years (4 lists) ago
it was enough for a top spot.

https://www.top500.org/lists/green500/2021/11/

Re: Architecture comparison

<29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25181&group=comp.arch#25181

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5b50:0:b0:2f3:ae99:8e0 with SMTP id n16-20020ac85b50000000b002f3ae9908e0mr20674397qtw.669.1652212841506;
Tue, 10 May 2022 13:00:41 -0700 (PDT)
X-Received: by 2002:a4a:5894:0:b0:35e:b78c:2ca9 with SMTP id
f142-20020a4a5894000000b0035eb78c2ca9mr8677322oob.56.1652212841192; Tue, 10
May 2022 13:00:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 10 May 2022 13:00:40 -0700 (PDT)
In-Reply-To: <3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:a0da:736:be6c:6d2c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:a0da:736:be6c:6d2c
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me> <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org> <3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>
Subject: Re: Architecture comparison
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 10 May 2022 20:00:41 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Tue, 10 May 2022 20:00 UTC

On Tuesday, May 10, 2022 at 2:20:36 PM UTC-5, Michael S wrote:
> On Monday, May 9, 2022 at 10:29:40 AM UTC+3, Terje Mathisen wrote:
> > MitchAlsup wrote:
> > > On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
> > >> Albeit, in an instruction-for-instruction sense, I guess the ISA design
> > >> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
> > >> (where a RISC style ISA tends to need to execute more instructions for a
> > >> similar amount of work, at least when using Dhrystone as the metric).
> > > <
> > > This is a question about how one defines work.
> > > Floating point people do not count loads and stores--just FLOPs.
> > This is particularly galling when we consider how the relative costs of
> > memory access vs FPU operations have changed:
> >
> > I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> > RAM, vs less than 10 pJ for an FMUL.
> >
> > I.e. the loads are more than two orders of magnitude more expensive than
> > the FLOPs!
> > Terje
> >
> > --
> > - <Terje.Mathisen at tmsw.no>
> > "almost all programming can be viewed as an exercise in caching"
> The current Green500 champion (custom ASIC) delivers 39.379 GFlops/watts
> == 25.4 pJ/FLOP ~= 50 pJ/FMADD
<
I assume these are with the memory reference footprint. But are they ?
<
> The best GPGPU is not far behind at 33.983 GFlops/watts
> The best CPU is further down at 16.876 GFlops/watts. Only 2 years (4 lists) ago
> it was enough for a top spot.
>
> https://www.top500.org/lists/green500/2021/11/

Re: Architecture comparison

<t5ehli$iqh$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25182&group=comp.arch#25182

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison
Date: Tue, 10 May 2022 15:23:03 -0500
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <t5ehli$iqh$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me>
<1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me>
<b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org>
<3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>
<29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 10 May 2022 20:24:18 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6fad1b8eaaa2f0d0449235de8e2e6b99";
logging-data="19281"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EysZnUyMs/qm5MC0HGtvW"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:V9lFjCuvcBfdkaTV1Rz6lRsDWmA=
In-Reply-To: <29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>
Content-Language: en-US
 by: BGB - Tue, 10 May 2022 20:23 UTC

On 5/10/2022 3:00 PM, MitchAlsup wrote:
> On Tuesday, May 10, 2022 at 2:20:36 PM UTC-5, Michael S wrote:
>> On Monday, May 9, 2022 at 10:29:40 AM UTC+3, Terje Mathisen wrote:
>>> MitchAlsup wrote:
>>>> On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
>>>>> Albeit, in an instruction-for-instruction sense, I guess the ISA design
>>>>> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
>>>>> (where a RISC style ISA tends to need to execute more instructions for a
>>>>> similar amount of work, at least when using Dhrystone as the metric).
>>>> <
>>>> This is a question about how one defines work.
>>>> Floating point people do not count loads and stores--just FLOPs.
>>> This is particularly galling when we consider how the relative costs of
>>> memory access vs FPU operations have changed:
>>>
>>> I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
>>> RAM, vs less than 10 pJ for an FMUL.
>>>
>>> I.e. the loads are more than two orders of magnitude more expensive than
>>> the FLOPs!
>>> Terje
>>>
>>> --
>>> - <Terje.Mathisen at tmsw.no>
>>> "almost all programming can be viewed as an exercise in caching"
>> The current Green500 champion (custom ASIC) delivers 39.379 GFlops/watts
>> == 25.4 pJ/FLOP ~= 50 pJ/FMADD
> <
> I assume these are with the memory reference footprint. But are they ?
> <

Such is the problem...

Too many of these sorts of benchmarks are basically people doing vector
operations in tight loops with little else going on (such as accessing
memory), because doing anything else would ruin their GFLOPs numbers...

It is like, in my case, one could write a loop in a way that
theoretically does 600 million 16-bit (or 300 million 32-bit) integer
additions per second at 50 MHz...

Eg, a whole lot of:
PADD.W | PADD.W | PADD.W
Or:
PADD.L | PADD.L | PADD.L

But, it would be, "kinda useless"...

Memory seems to be what eats power, and the great performance limiter
for CPU cores both big and small...

I have often noted that memory-saving tricks can often pay for
themselves even if (in theory) they may increase the computational cost
of a given task.

>> The best GPGPU is not far behind at 33.983 GFlops/watts
>> The best CPU is further down at 16.876 GFlops/watts. Only 2 years (4 lists) ago
>> it was enough for a top spot.
>>
>> https://www.top500.org/lists/green500/2021/11/

Re: Architecture comparison

<57a34e24-1fa7-4c54-896d-3e619119117dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25184&group=comp.arch#25184

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7f43:0:b0:2f3:d55d:7296 with SMTP id g3-20020ac87f43000000b002f3d55d7296mr12786678qtk.635.1652214887334;
Tue, 10 May 2022 13:34:47 -0700 (PDT)
X-Received: by 2002:a05:6871:438b:b0:ee:326d:b3f9 with SMTP id
lv11-20020a056871438b00b000ee326db3f9mr1111886oab.126.1652214887086; Tue, 10
May 2022 13:34:47 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 10 May 2022 13:34:46 -0700 (PDT)
In-Reply-To: <29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a0d:6fc2:55b0:ca00:65dd:bb7:48b5:b678;
posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 2a0d:6fc2:55b0:ca00:65dd:bb7:48b5:b678
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <0001HW.28287BAE0057416370000574538F@news.individual.net>
<t59i4h$bov$1@dont-email.me> <1e9f8149-81ac-441f-bf18-1235d299f6cdn@googlegroups.com>
<t59rno$7rm$1@dont-email.me> <b287b230-a7b6-4e04-a76a-7c4fb95d221en@googlegroups.com>
<t5afsu$1kd5$1@gioia.aioe.org> <3a1534c2-1ccf-4927-9eca-777a0d0a5bc7n@googlegroups.com>
<29a22c78-15f4-49a0-a61b-f40feec44391n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <57a34e24-1fa7-4c54-896d-3e619119117dn@googlegroups.com>
Subject: Re: Architecture comparison
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 10 May 2022 20:34:47 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4711
 by: Michael S - Tue, 10 May 2022 20:34 UTC

On Tuesday, May 10, 2022 at 11:00:42 PM UTC+3, MitchAlsup wrote:
> On Tuesday, May 10, 2022 at 2:20:36 PM UTC-5, Michael S wrote:
> > On Monday, May 9, 2022 at 10:29:40 AM UTC+3, Terje Mathisen wrote:
> > > MitchAlsup wrote:
> > > > On Sunday, May 8, 2022 at 8:45:31 PM UTC-5, BGB wrote:
> > > >> Albeit, in an instruction-for-instruction sense, I guess the ISA design
> > > >> would seem to explain how a "VAX MIPS" is seemingly a hard unit to match
> > > >> (where a RISC style ISA tends to need to execute more instructions for a
> > > >> similar amount of work, at least when using Dhrystone as the metric).
> > > > <
> > > > This is a question about how one defines work.
> > > > Floating point people do not count loads and stores--just FLOPs.
> > > This is particularly galling when we consider how the relative costs of
> > > memory access vs FPU operations have changed:
> > >
> > > I have seen quotes of over 1000 pJ (1200?) to load a 64-bit double from
> > > RAM, vs less than 10 pJ for an FMUL.
> > >
> > > I.e. the loads are more than two orders of magnitude more expensive than
> > > the FLOPs!
> > > Terje
> > >
> > > --
> > > - <Terje.Mathisen at tmsw.no>
> > > "almost all programming can be viewed as an exercise in caching"
> > The current Green500 champion (custom ASIC) delivers 39.379 GFlops/watts
> > == 25.4 pJ/FLOP ~= 50 pJ/FMADD
> <
> I assume these are with the memory reference footprint. But are they ?

Green500 has the same rules as Top500.
The benchmark used is Linpack’s “Highly Parallel Computing” benchmark.
FAQ: https://www.top500.org/resources/frequently-asked-questions/
The complete rules can be found here: http://www.netlib.org/benchmark/hpl/
Short summary: do LU decomposition followed by solver for suqare matrix of
the size of your choice. Use any optimization you can think about that does not
harm a precision of result beyond specified problem-size-dependent margin.

I suppose that well-optimized run will have less than one byte (I mean byte, not any sort of word)
of external memory read+written per 100 FLOPs and approximately 1-2 bytes read+written per FLOP
from/to L1D cache or from/to GPU/ASIC equivalent of L1D cache.
I'd guess that in this benchmark system interconnects are bigger energy consumer them DRAM access.

> <
> > The best GPGPU is not far behind at 33.983 GFlops/watts
> > The best CPU is further down at 16.876 GFlops/watts. Only 2 years (4 lists) ago
> > it was enough for a top spot.
> >
> > https://www.top500.org/lists/green500/2021/11/

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25187&group=comp.arch#25187

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1a9c:b0:2f3:d873:4acc with SMTP id s28-20020a05622a1a9c00b002f3d8734accmr12380235qtc.424.1652221668435;
Tue, 10 May 2022 15:27:48 -0700 (PDT)
X-Received: by 2002:a05:6808:6d7:b0:325:67ff:a21b with SMTP id
m23-20020a05680806d700b0032567ffa21bmr1102053oih.105.1652221668180; Tue, 10
May 2022 15:27:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 10 May 2022 15:27:47 -0700 (PDT)
In-Reply-To: <68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:6947:3c86:73e1:a64e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:6947:3c86:73e1:a64e
References: <t4peor$cch$1@dont-email.me> <91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com> <t4q2cn$l82$1@gal.iecc.com>
<t4qlfi$42b$1@dont-email.me> <t4qsuk$77p$1@newsreader4.netcologne.de>
<t4s55s$ine$1@dont-email.me> <80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me> <68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Tue, 10 May 2022 22:27:48 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2015
 by: Quadibloc - Tue, 10 May 2022 22:27 UTC

On Sunday, May 8, 2022 at 4:41:43 PM UTC-6, MitchAlsup wrote:

> Why do people always forget about the 8085 ??

Not enough machines were made using it so that software
applications were written that used 8085 instructions that the
8080 didn't have.

It didn't make much of a historical 'splash', even if at least one
book was written about it.

John Savard

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t5esln$htk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25190&group=comp.arch#25190

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Tue, 10 May 2022 16:32:05 -0700
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <t5esln$htk$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
<b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 10 May 2022 23:32:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fbbecb92e5a9ebadca532578df33c56a";
logging-data="18356"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LxY3/BQNbAAhF2Hpb3ea64CNVD01+SEM="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:KHnU7qXX6ZnYcxoPICNIRQLu3zw=
In-Reply-To: <b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>
Content-Language: en-US
 by: Stephen Fuld - Tue, 10 May 2022 23:32 UTC

On 5/10/2022 3:27 PM, Quadibloc wrote:
> On Sunday, May 8, 2022 at 4:41:43 PM UTC-6, MitchAlsup wrote:
>
>> Why do people always forget about the 8085 ??
>
> Not enough machines were made using it so that software
> applications were written that used 8085 instructions that the
> 8080 didn't have.

It was used in a lot of embedded systems, as it led to lower cost
systems than the 8080 and had a few features that helped there.

> It didn't make much of a historical 'splash', even if at least one
> book was written about it.

Embedded processors rarely make a "splash" in consumer consciousness.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t5evje$2ru$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25192&group=comp.arch#25192

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Tue, 10 May 2022 19:20:41 -0500
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <t5evje$2ru$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
<b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>
<t5esln$htk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 May 2022 00:22:06 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7155b3a29c990c92a41c6ff303f1405a";
logging-data="2942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18htUuDWafQ3LNAHzmbk5Hr"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Cancel-Lock: sha1:FKxVnDS4A/hHYxasJzeaeTwAJyU=
In-Reply-To: <t5esln$htk$1@dont-email.me>
Content-Language: en-US
 by: BGB - Wed, 11 May 2022 00:20 UTC

On 5/10/2022 6:32 PM, Stephen Fuld wrote:
> On 5/10/2022 3:27 PM, Quadibloc wrote:
>> On Sunday, May 8, 2022 at 4:41:43 PM UTC-6, MitchAlsup wrote:
>>
>>> Why do people always forget about the 8085 ??
>>
>> Not enough machines were made using it so that software
>> applications were written that used 8085 instructions that the
>> 8080 didn't have.
>
> It was used in a lot of embedded systems, as it led to lower cost
> systems than the 8080 and had a few features that helped there.
>
>
>> It didn't make much of a historical 'splash', even if at least one
>> book was written about it.
>
> Embedded processors rarely make a "splash" in consumer consciousness.
>

Yeah, 8085 is sorta like the 80186.
Sorta existed, mostly forgotten about.

I guess also things "like its predecessor, but only slight improvements,
but not backwards compatible" is also sort of a deal-breaker.

So, for example, people went with the 80286 which was at least backwards
compatible with the 8086.

....

Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)

<t5fm22$73d$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25195&group=comp.arch#25195

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Architecture comparison (was: Upcoming DFP support in clang/LLVM)
Date: Tue, 10 May 2022 23:45:22 -0700
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <t5fm22$73d$1@dont-email.me>
References: <t4peor$cch$1@dont-email.me>
<91cffebb-ddec-4f70-b790-fbe5645eec3dn@googlegroups.com>
<97a308cb-943b-4a24-b12d-cbb3ab2d8a56n@googlegroups.com>
<t4q2cn$l82$1@gal.iecc.com> <t4qlfi$42b$1@dont-email.me>
<t4qsuk$77p$1@newsreader4.netcologne.de> <t4s55s$ine$1@dont-email.me>
<80fc57f0-86b3-4977-86e0-242d3c3c3b3an@googlegroups.com>
<t4sans$smp$1@dont-email.me> <2022May8.160036@mips.complang.tuwien.ac.at>
<t59b2e$nd2$1@dont-email.me>
<68f71607-f7db-48c0-a118-d516c5590224n@googlegroups.com>
<b051e827-b128-4007-941e-d4b345e997b2n@googlegroups.com>
<t5esln$htk$1@dont-email.me> <t5evje$2ru$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 May 2022 06:45:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="00d72bc1e63b2f22ff36716eec57d87d";
logging-data="7277"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Y00D2fmm/Sp69zr7fM0W9uEUo/U7uTqU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:OmbohTT0SDYyXgiM9hj6Q1aCXXI=
In-Reply-To: <t5evje$2ru$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Wed, 11 May 2022 06:45 UTC

On 5/10/2022 5:20 PM, BGB wrote:
> On 5/10/2022 6:32 PM, Stephen Fuld wrote:
>> On 5/10/2022 3:27 PM, Quadibloc wrote:
>>> On Sunday, May 8, 2022 at 4:41:43 PM UTC-6, MitchAlsup wrote:
>>>
>>>> Why do people always forget about the 8085 ??
>>>
>>> Not enough machines were made using it so that software
>>> applications were written that used 8085 instructions that the
>>> 8080 didn't have.
>>
>> It was used in a lot of embedded systems, as it led to lower cost
>> systems than the 8080 and had a few features that helped there.
>>
>>
>>> It didn't make much of a historical 'splash', even if at least one
>>> book was written about it.
>>
>> Embedded processors rarely make a "splash" in consumer consciousness.
>>
>
> Yeah, 8085 is sorta like the 80186.
> Sorta existed, mostly forgotten about.
>
>
> I guess also things "like its predecessor, but only slight improvements,
> but not backwards compatible" is also sort of a deal-breaker.

8085 was software compatible with the 8080. And from a hardware
perspective needing only one voltage in instead of three for the 8080
was more than a "slight" improvement.

https://en.wikipedia.org/wiki/Intel_8085

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor