On 12/13/2023 7:14 AM, Quadibloc wrote:
> On Wed, 13 Dec 2023 12:31:50 +0000, Quadibloc wrote:
>
>> On Wed, 13 Dec 2023 05:09:52 +0000, Quadibloc wrote:
>>
>>> the trick to keeping it simple would be to have _two_ sets of prefix
>>> bits, because there are only a few lengths for instructions, and a few
>>> lengths for constants used as immediates - it's only the _combinations_
>>> that get out of control.
>>
>> Actually, there is one other thing. So that the instructions for which
>> immediates are used can have one consistent format, unlike the prefixes
>> for instruction length, which can have different numbers of bits, the
>> prefixes for constant length need to all be the same number of bits in
>> length.
>
> I went back and checked. When I proposed what a variable-length coding
> for the Concertina instruction set would look like, at first glance it
> seemed as though I didn't follow that rule:
>
> Something like:
>
> 0 - 16 bits
> 1 - 32 bits, except
> 111011001 32 bits + 16 bits
> 111011010 32 bits + 32 bits
> 111011011 32 bits + 64 bits
> 1110111000 32 bits + 48 bits
> 1110111001 32 bits + 32 bits
> 1110111010 32 bits + 64 bits
> 1110111011 32 bits + 128 bits
> 11110 - 48 bits
> 11111 - 64 bits
>

Ideally, one wants to minimize the number of bits one needs to check.
But, as-is, with both the XGPR scheme and RISC-V thrown in the mix, this
gets annoying.

So, we have:
8 bits from the instruction (to cover the various modes in BJX2);
2 more bits for RISC-V (since it uses different bits);
3 more bits to indicate the mode:
WXE: Is WEX enabled or are we only executing scalar instructions?
RV: Is the CPU in RISC-V Mode;
XG2: Is the CPU in XG2 Mode.
Setting both XG2 and RV means XG2RV Mode.

An XG2-Only core would only need to look at 4 bits.
A Fix32 Core would look at 0 bits (and could also use a cheaper I$ design).

But, XGPR made a mess by '7zzz' and '9zzz' also signaling the start of a
32-bit instruction (vs, only Ezzz and Fzzz as it was originally)

To deal with everything in Baseline-Only (no XGPR), would need 6 bits.

Timing did become a problem with this, but then came up with the option
of sorting this out (for every possible instruction word) when a
cache-line arrives on the bus, and then storing it along with the
(address) in the metadata bits for the cache-line.

Though, ended up storing 32 bits of metadata for this (4 bits for each
word), before later realizing I could have gotten away with 2 bits per
word (for 16 bits of metadata per cache-line).

Does have the drawback that now I$ lines are only valid if they also
happen to be in the same CPU mode.

If one tries to handle superscalar during Fetch, things are is likely to
get "very ugly, very fast". Though, one possible option could be to add
stages to determine and mask superscalar sequences as the line arrives
on the bus, with maybe 1 or 2 extra "pad cycles" to sort out whether
instructions can be executed in parallel:

Then again, it is possible that it could be possible to identify
superscalar cases without adding latency.

In this case, the flag bits would likely also need to be passed to the
decode stage (and would function similar to WEX bits, but also applied
to RISC-V ops and similar).

> But notice that the lengths 32 and 64 bits appear twice. So this
> actually was intended to keep the instruction format constant;
> the prifixes that were one bit longer were for floating-point
> instructions. While both integer and floating-point instructions
> use register banks of 32 registers, the difference is that there
> are two load-store instructions for floats - LOAD and STORE -
> for integers there are also (where the integer type is shorter than
> the register) LOAD UNSIGNED (zero out all unused higher bits) and
> INSERT (leave all higher bits unaffected) in addition to LOAD
> (sign extend into all unused bits of the register more significant
> than the leading bit of the argument type).
>
> So I did know of that principle, and was following it, with a
> slight customization for the specifics of the Concertina II
> instruction set.
>
> John Savard

On Tue, 12 Dec 2023 18:27:50 -0500, "Paul A. Clayton"
<paaronclayton@gmail.com> wrote:

>On 12/10/23 11:45?AM, John Levine wrote:
>> According to MitchAlsup <mitchalsup@aol.com>:
>>> :
>>> Johnson used an iterative technique of proposing a machine, writing a compiler, measuring
>>> the results to propose a better machine, and then repeating the cycle over a dozen times.
>>> Though the initial intent was not specifically to come up with a simple design, the result
>>> was a RISC-like 32-bit architecture whose code density was as compact as the PDP-11 and
>>> VAX [Johnson79].
>>
>> Yup. If anyone can find that Johnson tech report I'd like to read it.
>> Some googlage only found references to it.
>
>It looks like one can get a PDF from Semantic Scholar:
>https://www.semanticscholar.org/paper/A-32-bit-processor-design-Johnson/5ef2b3e8a755a2c29833eba8ab61117c296d95ac
>
>I have a PDF on my computer that I can email to anyone interested
>(paaronclayton is my gmail address).

Seems the server that hosted that paper is no longer operating.

On 13/12/2023 20:06, MitchAlsup wrote:
> David Brown wrote:
>
>> On 10/12/2023 11:39, Thomas Koenig wrote:
>>> MitchAlsup <mitchalsup@aol.com> schrieb:
>>>
>>>> Question (to everyone):: Has your word processor or spreadsheet
>>>> added anything USEFUL TO YOU since 2000 ??
>>>
>>> In my case: Yes.
>>>
>>> Besides making many things worse, the new formula editor (since
>>> 2010?) in Word is reasonable to work with, especially since it is
>>> possible to use LaTeX notation now (and thus it is now possible
>>> to paste from Maple).
>>>
>
>> If I want to write something serious with formula, I use LaTeX.
>
> When I want to write an unmisunderstandable formula I use CorelDraw
> and then export as *.jpg. {Everything, except NGs like this, can take
> *.jpgs.} And a Draw program can create symbols that are not in char-
> acture Maps.

Drawing programs can be useful if you want some unusual symbols (though
they would have to be /very/ unusual if they are not in some package on
CTAN). And of course you can be /much/ freer with the layout of the maths.

If I needed something with such freehand layout, I'd write it on paper
and scan it in, as it is much faster to do. That's also fine for notes,
or documentation only read by the development team. But it is not
"professional" quality, if that is important for the job in hand.

If you are making such files, I'd suggest png as a better format than
jpg - it is far better suited to sharp contrast images. jpg is for
photographs and similar images, and will blur the lines and figures on
drawn maths. (Or use a vector image format, like svg.)

On 13/12/2023 23:40, MitchAlsup wrote:
> David Brown wrote:
>
>> On 10/12/2023 11:39, Thomas Koenig wrote:
>>> MitchAlsup <mitchalsup@aol.com> schrieb:
>>>
>>>> Question (to everyone):: Has your word processor or spreadsheet
>>>> added anything USEFUL TO YOU since 2000 ??
>>>
>>> In my case: Yes.
>>>
>>> Besides making many things worse, the new formula editor (since
>>> 2010?) in Word is reasonable to work with, especially since it is
>>> possible to use LaTeX notation now (and thus it is now possible
>>> to paste from Maple).
>>>
>
>> If I want to write something serious with formula, I use LaTeX.
>
>>> Previously, I actually wrote some reports in LaTeX, going to some
>>> trouble to make them appear visually like the Word template du jour
>>> (but the formulas gave it away, they looked to nice for Word).
>>>
>
>> What a strange thing to do - that sounds completely backwards to me!
>
>> I was happy when I had made a template for LibreOffice (it might have
>> been one of the forks of OpenOffice, pre-LibreOffice) that looked
>> similar to what I have for LaTeX.  Then I could make
>> reasonable-looking documents for customers that insisted on having
>> docx format instead of pdf.
>
>> I don't think there has been much exciting or important (to me) added
>> to word processors for decades.  Direct pdf generation was one, which
>> probably existed in Star Office (the ancestor of OpenOffice /
>
> *.pdf arrives in Word ~2000 (maybe before).

Word 2007, according to Wikipedia, google, and the never-wrong internet
community. Prior to that, people used "pdf printers" which gave basic
pdf output (image only - no links, contents, cross-references, etc.).
Or they did a lot of manual work using expensive Adobe Acrobat Writer
tools so that they could add the "active" bits.

My experience with MS Office is mostly in helping others - I haven't had
that overrated, overpriced monstrosity on a computer since Word for
Windows 2.0 on Windows 3.1. But it seems that these days it does a lot
better job at exporting pdfs than it used to. I did a quick test with
online Office 365 with an old LibreOffice document, and Office 365 did
get the table of contents right when exporting, and the cross-references
had the right section numbers and were clickable. But if failed to get
the cross-referenced section names in the pdf, despite showing them fine
in the docx file it was editing. It was not an extensive test, and the
original document was written with LibreOffice, not MS Office. (It was
exported from LibreOffice in docx, thus it was in the official ISO
standard ooxml format, rather than the screwed up version of that which
MS Office prefers.)

>
> <snip>
>
>> Apart from that, the only benefits I see of newer LibreOffice over
>> older ones is better handling of the insane chaos that MS Office uses
>> for its file formats.  LibreOffice is /much/ better at this than MS
>> Office is, especially if the file has been modified by a number of
>> different MS Office versions.
>
> I still require people sending me *.docx to convert it back to
> WORD2003 format *.doc and retransmitting it. It is surprising how many
> people don't know how to do that.

It is surprising that anyone would want them to. Why not just install
LibreOffice, and have a tool that is better at reading MS Word generated
files than any version of MS Word ever was?

Of course, people should not be sending .docx or any other source-format
file unless they expect you to edit the document - finished documents
should always be sent in pdf format.

mitchalsup@aol.com (MitchAlsup) writes:
>David Brown wrote:
>
>> On 10/12/2023 11:39, Thomas Koenig wrote:
>>> MitchAlsup <mitchalsup@aol.com> schrieb:
>>>
>>>> Question (to everyone):: Has your word processor or spreadsheet
>>>> added anything USEFUL TO YOU since 2000 ??
>>>
>>> In my case: Yes.
>>>
>>> Besides making many things worse, the new formula editor (since
>>> 2010?) in Word is reasonable to work with, especially since it is
>>> possible to use LaTeX notation now (and thus it is now possible
>>> to paste from Maple).
>>>
>
>> If I want to write something serious with formula, I use LaTeX.
>
>>> Previously, I actually wrote some reports in LaTeX, going to some
>>> trouble to make them appear visually like the Word template du jour
>>> (but the formulas gave it away, they looked to nice for Word).
>>>
>
>> What a strange thing to do - that sounds completely backwards to me!
>
>> I was happy when I had made a template for LibreOffice (it might have
>> been one of the forks of OpenOffice, pre-LibreOffice) that looked
>> similar to what I have for LaTeX. Then I could make reasonable-looking
>> documents for customers that insisted on having docx format instead of pdf.
>
>> I don't think there has been much exciting or important (to me) added to
>> word processors for decades. Direct pdf generation was one, which
>> probably existed in Star Office (the ancestor of OpenOffice /
>
>*.pdf arrives in Word ~2000 (maybe before).

Are you sure about that? IIRC it was a decade later before
adobe wasn't required.

<snip>

>I still require people sending me *.docx to convert it back to
>WORD2003 format *.doc and retransmitting it. It is surprising how
>many people don't know how to do that.

I ask for PDF's. I have no ability to read windows office formats
of any type without using star/open/libre office, and I detest WYSIWYG
word processors of all stripes.

David Brown wrote:

> On 13/12/2023 23:40, MitchAlsup wrote:
>>
>>
>>> I was happy when I had made a template for LibreOffice (it might have
>>> been one of the forks of OpenOffice, pre-LibreOffice) that looked
>>> similar to what I have for LaTeX.  Then I could make
>>> reasonable-looking documents for customers that insisted on having
>>> docx format instead of pdf.
>>
>>> I don't think there has been much exciting or important (to me) added
>>> to word processors for decades.  Direct pdf generation was one, which
>>> probably existed in Star Office (the ancestor of OpenOffice /
>>
>> *.pdf arrives in Word ~2000 (maybe before).

> Word 2007, according to Wikipedia, google, and the never-wrong internet
> community.

I worked at AMD 1999-2006 and we used save as to *.pdf all the time.
{This would have been the professional version of WORD/Office.}
The student version 2003 also has this, I still have the CD-ROM.

MitchAlsup wrote:
>> On 12/13/2023 8:47 AM, EricP wrote:
>
>>> And, as in my case, there could be multiple branch offset sizes
>>> which interacts with the length parse, sign extension delay,
>>> and the final RIP add result delay.
>
> So, have 1 size for conditional and 1 size for unconditional--

I have 2 branch formats, one for small 16b size offset with 16b opspec,
and one for medium 32b and large 64b offsets with 32b opspec,

Later I added a 3rd format for compare and branch when there are
two variable size immediates, one for offset and one for compare value.
The offset is the first immediate so it starts in a known buffer location.

> AND THEN, you build a sign extending adder that adds 64+16 and
> produces the correct sign extended 64-bit result. Guys it is not
> 1975 anymore !! Why do you think this is a serial process ??

I didn't say serial.
I was thinking of starting all 3 offsets sizes 16b, 32b, 64b,
adds immediately before knowing the instruction type or size,
then use the actual type and size to select the correct result.
The 64b adds could be further subdivided as 4 * 16b adders then
combine the size select with 16b carry select to assemble a 64b result.

Which is why I said I thought this was just a mux delay at the end.

> Also Note:: The address produced by the branch target adder only
> needs to produce enough bits to index the cache {you can sort out
> all the harder stuff later} in the DECODE stage of the pipeline.
> A check for page crossing (because you don't necessarily need to access
> the TLB) finishes the problem.

In the hypothetical design I have in mind the instruction bytes
get parsed from fetch buffers, whose job is to hide the pipeline
latency to I$L1, and also allow prefetch for possible alternate path.
It also allows local looping and replay out of the fetch buffers.

In that design the full 64b parse RIP is need as a tag for
selecting from the multiple fetch buffers.

EricP wrote:

> MitchAlsup wrote:
>>> On 12/13/2023 8:47 AM, EricP wrote:
>>
>>>> And, as in my case, there could be multiple branch offset sizes
>>>> which interacts with the length parse, sign extension delay,
>>>> and the final RIP add result delay.
>>
>> So, have 1 size for conditional and 1 size for unconditional--

> I have 2 branch formats, one for small 16b size offset with 16b opspec,
> and one for medium 32b and large 64b offsets with 32b opspec,

> Later I added a 3rd format for compare and branch when there are
> two variable size immediates, one for offset and one for compare value.
> The offset is the first immediate so it starts in a known buffer location.

>> AND THEN, you build a sign extending adder that adds 64+16 and
>> produces the correct sign extended 64-bit result. Guys it is not
>> 1975 anymore !! Why do you think this is a serial process ??

> I didn't say serial.
> I was thinking of starting all 3 offsets sizes 16b, 32b, 64b,
> adds immediately before knowing the instruction type or size,
> then use the actual type and size to select the correct result.
> The 64b adds could be further subdivided as 4 * 16b adders then
> combine the size select with 16b carry select to assemble a 64b result.

> Which is why I said I thought this was just a mux delay at the end.

I am trying to tell you to put that mux in the subsequent cycle.

A 16-bit address can access a 64KB cache. A 64KB cache is bigger than
we will be willing to build. So, to access the cache all we need is
the lower order bits, and all 3 formats are the same here, so we
add 16 bits and start accessing the cache, Then we flop the carry out
and in the subsequent cycle we add the bits bigger than 16 while the
cache is being accessed. And now at the time when the tag is available
so is the rest of the address bits.

>> Also Note:: The address produced by the branch target adder only
>> needs to produce enough bits to index the cache {you can sort out
>> all the harder stuff later} in the DECODE stage of the pipeline.
>> A check for page crossing (because you don't necessarily need to access
>> the TLB) finishes the problem.

> In the hypothetical design I have in mind the instruction bytes
> get parsed from fetch buffers, whose job is to hide the pipeline
> latency to I$L1, and also allow prefetch for possible alternate path.
> It also allows local looping and replay out of the fetch buffers.

I call this the instruction buffer and hold both sequential and
alternate path instructions for decode. I can access a whole cache
line per cycle, so I have little problem feeding the sequential
path--but instead of fetching whole cache lines, I fetch four ¼
cache lines and a next fetch predictor. Each I$ access uses a
7-bit index and a 3-bit set {turning the 4-way cache into direct
mapped cache} and another 7+bit index to the fetch predictor.

void accessICache(Fetch fetch)
{ static Index index;

for( i = 0; i < SETS; i++ )
InstBuf[fetch+i] = column[i].SRAM[index[i]];
index = FetchPredictor[index[5]];
}

> In that design the full 64b parse RIP is need as a tag for
> selecting from the multiple fetch buffers.

On 12/14/2023 6:41 AM, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup) writes:
>> David Brown wrote:
>>
>>> On 10/12/2023 11:39, Thomas Koenig wrote:
>>>> MitchAlsup <mitchalsup@aol.com> schrieb:
>>>>
>>>>> Question (to everyone):: Has your word processor or spreadsheet
>>>>> added anything USEFUL TO YOU since 2000 ??
>>>>
>>>> In my case: Yes.
>>>>
>>>> Besides making many things worse, the new formula editor (since
>>>> 2010?) in Word is reasonable to work with, especially since it is
>>>> possible to use LaTeX notation now (and thus it is now possible
>>>> to paste from Maple).
>>>>
>>
>>> If I want to write something serious with formula, I use LaTeX.
>>
>>>> Previously, I actually wrote some reports in LaTeX, going to some
>>>> trouble to make them appear visually like the Word template du jour
>>>> (but the formulas gave it away, they looked to nice for Word).
>>>>
>>
>>> What a strange thing to do - that sounds completely backwards to me!
>>
>>> I was happy when I had made a template for LibreOffice (it might have
>>> been one of the forks of OpenOffice, pre-LibreOffice) that looked
>>> similar to what I have for LaTeX. Then I could make reasonable-looking
>>> documents for customers that insisted on having docx format instead of pdf.
>>
>>> I don't think there has been much exciting or important (to me) added to
>>> word processors for decades. Direct pdf generation was one, which
>>> probably existed in Star Office (the ancestor of OpenOffice /
>>
>> *.pdf arrives in Word ~2000 (maybe before).
>
> Are you sure about that? IIRC it was a decade later before
> adobe wasn't required.
>
> <snip>
>
>> I still require people sending me *.docx to convert it back to
>> WORD2003 format *.doc and retransmitting it. It is surprising how
>> many people don't know how to do that.
>
> I ask for PDF's. I have no ability to read windows office formats
> of any type without using star/open/libre office, and I detest WYSIWYG
> word processors of all stripes.

Try to stay far away from windows office docs, they can be filled with
interesting macros, well back in the day! I do remember a lot of print
to PDF programs. Mock up a printer device, print, produce a file.

On 12/13/23 2:09 AM, Anton Ertl wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>> It looks like one can get a PDF from Semantic Scholar:
>> https://www.semanticscholar.org/paper/A-32-bit-processor-design-Johnson/5ef2b3e8a755a2c29833eba8ab61117c296d95ac
>
> The link to the PDF does not work for me.

I guess Bell Labs is now thoroughly extinct. (The modification
date on the file I have is 6 October 2011. I feel good about being
able to provide a few people with copies.)

> Anyway, looking at where it
> is coming from, this is likely to be a predecessor of the CRISP
> architecture.

One significant difference is the early C machine having 6 GPRs
plus SP and a zero register compared to 32(?) words at the start
of the stack frame, but there are significant similarities.

CRISP was also not just a paper design (I get the impression that
the previous studies were limited to simulation).

David Brown <david.brown@hesbynett.no> schrieb:
> On 10/12/2023 11:39, Thomas Koenig wrote:

>> Previously, I actually wrote some reports in LaTeX, going to some
>> trouble to make them appear visually like the Word template du jour
>> (but the formulas gave it away, they looked to nice for Word).
>>
>
> What a strange thing to do - that sounds completely backwards to me!

When you work at a company that prescribes (sort of) a certain
format, that is one possibility. I did the cover sheet in Word,
though, and pasted it together as PDF.

George Neuner <gneuner2@comcast.net> schrieb:
> On Sun, 10 Dec 2023 10:56:36 -0000 (UTC), Thomas Koenig
><tkoenig@netcologne.de> wrote:

[...]

>>My personal favorites for parallel programming are PGAS languages
>>like (yes, you guessed it) Fortran, where the central data
>>structure is the coarray.
>
> Mileage varies considerably and I don't intend to start a language
> war: a lot has to due with the history of parallel applications a
> person has developed. I can respect your point of view even though I
> don't agree with it.
>
> My favorite model is CSP (ala Hoare) with no shared memory. Which is
> not to say I don't use threads, but I try to design programs such that
> threads (mostly) are not sharing writable data structures.

Which is a sound idea, Inadvertently shared variables are a major
source of errors in OpenMP, for example.

>>You have to make sure that you synchronize before accessing data
>>that has been modified on another image.
>
> And that's where most languages fall down: they provide either
> primitives which are too low level and too hard to use correctly, or
> they provide high level mechanisms that don't scale well and are too
> limiting in actual use.

I think Fortran has gotten many things right here, at least for the
domain of scientific computing - the complexity is manageable.

For those who are interested, I've written a short tutorial about
Fortran coarrays, which can be found at

https://github.com/tkoenig1/coarray-tutorial/blob/main/tutorial.md

On 15/12/2023 03:59, Chris M. Thomasson wrote:
> On 12/14/2023 6:41 AM, Scott Lurndal wrote:
>> mitchalsup@aol.com (MitchAlsup) writes:
>>> David Brown wrote:
>>>
>>>> On 10/12/2023 11:39, Thomas Koenig wrote:
>>>>> MitchAlsup <mitchalsup@aol.com> schrieb:
>>>>>
>>>>>> Question (to everyone):: Has your word processor or spreadsheet
>>>>>> added anything USEFUL TO YOU since 2000 ??
>>>>>
>>>>> In my case: Yes.
>>>>>
>>>>> Besides making many things worse, the new formula editor (since
>>>>> 2010?) in Word is reasonable to work with, especially since it is
>>>>> possible to use LaTeX notation now (and thus it is now possible
>>>>> to paste from Maple).
>>>>>
>>>
>>>> If I want to write something serious with formula, I use LaTeX.
>>>
>>>>> Previously, I actually wrote some reports in LaTeX, going to some
>>>>> trouble to make them appear visually like the Word template du jour
>>>>> (but the formulas gave it away, they looked to nice for Word).
>>>>>
>>>
>>>> What a strange thing to do - that sounds completely backwards to me!
>>>
>>>> I was happy when I had made a template for LibreOffice (it might have
>>>> been one of the forks of OpenOffice, pre-LibreOffice) that looked
>>>> similar to what I have for LaTeX.  Then I could make reasonable-looking
>>>> documents for customers that insisted on having docx format instead
>>>> of pdf.
>>>
>>>> I don't think there has been much exciting or important (to me)
>>>> added to
>>>> word processors for decades.  Direct pdf generation was one, which
>>>> probably existed in Star Office (the ancestor of OpenOffice /
>>>
>>> *.pdf arrives in Word ~2000 (maybe before).
>>
>> Are you sure about that?  IIRC it was a decade later before
>> adobe wasn't required.
>>
>>   <snip>
>>
>>> I still require people sending me *.docx to convert it back to
>>> WORD2003 format *.doc and retransmitting it. It is surprising how
>>> many people don't know how to do that.
>>
>> I ask for PDF's.   I have no ability to read windows office formats
>> of any type without using star/open/libre office, and I detest WYSIWYG
>> word processors of all stripes.
>
> Try to stay far away from windows office docs, they can be filled with
> interesting macros, well back in the day! I do remember a lot of print
> to PDF programs. Mock up a printer device, print, produce a file.

They are only a problem if you use MS Office. LibreOffice, and its
predecessors, disable the macros by default.

PDF also supports dangerous links and Javascript. It's not a problem if
you use a decent pdf viewer, but if you use Adobe Acrobat on Windows,
you can definitely be at risk.

On 16/12/2023 14:49, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 10/12/2023 11:39, Thomas Koenig wrote:
>
>>> Previously, I actually wrote some reports in LaTeX, going to some
>>> trouble to make them appear visually like the Word template du jour
>>> (but the formulas gave it away, they looked to nice for Word).
>>>
>>
>> What a strange thing to do - that sounds completely backwards to me!
>
> When you work at a company that prescribes (sort of) a certain
> format, that is one possibility. I did the cover sheet in Word,
> though, and pasted it together as PDF.

Ah, your aim was to make the LaTeX documents look like the corporate
standard, which happened to be made in Word. That makes a lot more
sense. Typical out-of-the-box Word templates (and LibreOffice, and
every other word processor I have seen) all look amateur in comparison
to LaTeX layouts. But company standardisation trumps quality
typesetting. (And maybe you are one of the lucky people whose company
standard templates are well designed.)

On 12/6/23 2:54 AM, Anton Ertl wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
[snip]
>> One of my professors back in the late 70's was researching
>> data flow architectures. Perhaps it's time to reconsider the
>> unit of compute using single instructions, instead providing a
>> set of hardware 'functions' than can be used in a data flow environment.
>
> We already have data-flow microarchitectures since the mid-1990s, with
> the success of OoO execution. And the "von Neumann" ISAs have proven
> to be a good and long-term stable interface between software and these
> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
> and their microarchitectures turned out to be uncompetetive.

I suspect that a superior interface could be designed which
exploits diverse locality (i.e., data might naturally be closer to
some computational resources than to others) and communication
(and storage) costs and budgets (budgets being related to urgency
and importance). I think the original dataflow architectures
attempted to be very general with significant overhead for
readiness determination and communication. They also (as I
understand) lacked value prediction whereas OoO effectively uses
value prediction for branches.

While some computation operations may have variable latency, the
main variability seems to be in memory access. This implies that
dataflow at the level of compute operations need not be as
complex. Data availability for memory accesses also has some
deterministic factors with cache blocks larger than word size (or
even just larger than access size). Even such limited information
as knowing that an allocation will be 16-byte aligned might allow
simpler scheduling.

While the current interface does allow for significant improvement
exploiting common behaviors and dynamic microarchitectural
information, it does not seem (to me) an ideal interface.

I doubt an alternative interface will be adopted any time soon.
Even with a better understanding than in the 1970s, the problem is
not simple and early developments would not be competitive even if
all the R&D NRE was ignored. Maybe in a hundred years some AI will
develop such "for fun", by which time processor-centered general-
purpose computing may be as unusual as mechanical computing is
now.

On 12/18/2023 6:09 PM, Paul A. Clayton wrote:
> On 12/6/23 2:54 AM, Anton Ertl wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
> [snip]
>>> One of my professors back in the late 70's was researching
>>> data flow architectures.   Perhaps it's time to reconsider the
>>> unit of compute using single instructions, instead providing a
>>> set of hardware 'functions' than can be used in a data flow environment.
>>
>> We already have data-flow microarchitectures since the mid-1990s, with
>> the success of OoO execution.  And the "von Neumann" ISAs have proven
>> to be a good and long-term stable interface between software and these
>> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
>> and their microarchitectures turned out to be uncompetetive.
>
> I suspect that a superior interface could be designed which
> exploits diverse locality (i.e., data might naturally be closer to
> some computational resources than to others) and communication
> (and storage) costs and budgets (budgets being related to urgency
> and importance).

Fwiw, a fractal design sure seems to be able to maximize locality in
general, so to speak...

I think the original dataflow architectures
> attempted to be very general with significant overhead for
> readiness determination and communication. They also (as I
> understand) lacked value prediction whereas OoO effectively uses
> value prediction for branches.
>
> While some computation operations may have variable latency, the
> main variability seems to be in memory access. This implies that
> dataflow at the level of compute operations need not be as
> complex. Data availability for memory accesses also has some
> deterministic factors with cache blocks larger than word size (or
> even just larger than access size). Even such limited information
> as knowing that an allocation will be 16-byte aligned might allow
> simpler scheduling.
>
> While the current interface does allow for significant improvement
> exploiting common behaviors and dynamic microarchitectural
> information, it does not seem (to me) an ideal interface.
>
> I doubt an alternative interface will be adopted any time soon.
> Even with a better understanding than in the 1970s, the problem is
> not simple and early developments would not be competitive even if
> all the R&D NRE was ignored. Maybe in a hundred years some AI will
> develop such "for fun", by which time processor-centered general-
> purpose computing may be as unusual as mechanical computing is
> now.

Thomas Koenig wrote:

> George Neuner <gneuner2@comcast.net> schrieb:
>> On Sun, 10 Dec 2023 10:56:36 -0000 (UTC), Thomas Koenig
>><tkoenig@netcologne.de> wrote:

>>
>> And that's where most languages fall down: they provide either
>> primitives which are too low level and too hard to use correctly, or
>> they provide high level mechanisms that don't scale well and are too
>> limiting in actual use.

> I think Fortran has gotten many things right here, at least for the
> domain of scientific computing - the complexity is manageable.

> For those who are interested, I've written a short tutorial about
> Fortran coarrays, which can be found at

> https://github.com/tkoenig1/coarray-tutorial/blob/main/tutorial.md

Nicely done.

Notice how they specified "the what" without specifying "the how".
Notice that C and C++ atomics to the reverse.

Paul A. Clayton wrote:

> On 12/6/23 2:54 AM, Anton Ertl wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
> [snip]
>>> One of my professors back in the late 70's was researching
>>> data flow architectures. Perhaps it's time to reconsider the
>>> unit of compute using single instructions, instead providing a
>>> set of hardware 'functions' than can be used in a data flow environment.
>>
>> We already have data-flow microarchitectures since the mid-1990s, with
>> the success of OoO execution. And the "von Neumann" ISAs have proven
>> to be a good and long-term stable interface between software and these
>> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
>> and their microarchitectures turned out to be uncompetetive.

> I suspect that a superior interface could be designed which
> exploits diverse locality (i.e., data might naturally be closer to
> some computational resources than to others) and communication
> (and storage) costs and budgets (budgets being related to urgency
> and importance).

Consider the inner loop of DGEM on a properly resourced GBOoO::

LD |AGEN |cache|align|reslt|
LD |AGEN |cache|align|reslt|
FMUL | ex1 | ex2 | ex3 | ex4 |reslt|
FADD | ex1 | ex2 | ex3 |reslt|
ST |AGEN |cache|-----------------------------------------------|align|write|
LOOP | inc |

LD |AGEN |cache|align|reslt|
LD |AGEN |cache|align|reslt|
FMUL | ex1 | ex2 | ex3 | ex4 |reslt|
FADD | ex1 | ex2 | ex3 |reslt|
ST |AGEN |cache|-----------------------------------------------|align|write|
LOOP | inc |

LD |AGEN |cache|align|reslt|
LD |AGEN |cache|align|reslt|
FMUL | ex1 | ex2 | ex3 | ex4 |reslt|
FADD | ex1 | ex2 | ex3 |reslt|
ST |AGEN |cache|-----------------------------------------------|align|write|
LOOP | inc |

This is about as much Out-of-order one gets in a GBOoO machine.
Andy Glew would say that this is "not that much" out of order.
Notice that every function unit sees every operation in program
order and that the only OoO-ness is the latency of calculations.

> I think the original dataflow architectures
> attempted to be very general with significant overhead for
> readiness determination and communication. They also (as I
> understand) lacked value prediction whereas OoO effectively uses
> value prediction for branches.

The original data-flow architectures over did their ability to
discover parallelism. And whereas vonNeumann ISAs struggled to
find parallelism, data-flow architectures found "way too much".
They found so much parallelism that they got diverted down a
dark alley for a decade trying to "so manage" the parallelism
so their queuing structures did not overflow and crash the
machine. They stumbled upon parallelism in the 10s of millions
of instructions that could be fired each cycle. Primarily, they
failed in trying to reign in the parallelism down to the point
where they could build actual machines.

They died from finding too much not from finding too little.

I have made some further minor modifications.

I changed where, in the opcode space, the supplementary
memory-reference instructions were located. This allowed
me to have a few more bits available for them.

Also, I added a mechanism for a set of instructions
longer than 32 bits that can be used without
recourse to a block header of any kind, so that they
can be slipped into code in the format formerly
consisting purely of 32-bit instructions. This is very
inefficient, though, and so the previous format for
long instructions is also kept.

But this way, the basic instruction set used from
unblocked code is open-ended, which I think is important.

John Savard

On 12/18/2023 7:29 PM, MitchAlsup wrote:
> Paul A. Clayton wrote:
>
>> On 12/6/23 2:54 AM, Anton Ertl wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>> [snip]
>>>> One of my professors back in the late 70's was researching
>>>> data flow architectures.   Perhaps it's time to reconsider the
>>>> unit of compute using single instructions, instead providing a
>>>> set of hardware 'functions' than can be used in a data flow
>>>> environment.
>>>
>>> We already have data-flow microarchitectures since the mid-1990s, with
>>> the success of OoO execution.  And the "von Neumann" ISAs have proven
>>> to be a good and long-term stable interface between software and these
>>> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
>>> and their microarchitectures turned out to be uncompetetive.
>
>> I suspect that a superior interface could be designed which
>> exploits diverse locality (i.e., data might naturally be closer to
>> some computational resources than to others) and communication
>> (and storage) costs and budgets (budgets being related to urgency
>> and importance).
>
> Consider the inner loop of DGEM on a properly resourced GBOoO::
>
> LD     |AGEN |cache|align|reslt|
> LD     |AGEN |cache|align|reslt|
> FMUL                     | ex1 | ex2 | ex3 | ex4 |reslt|
> FADD                                             | ex1 | ex2 | ex3 |reslt|
> ST     |AGEN
> |cache|-----------------------------------------------|align|write|
> LOOP   | inc |
>
> LD           |AGEN |cache|align|reslt|
> LD           |AGEN |cache|align|reslt|
> FMUL                           | ex1 | ex2 | ex3 | ex4 |reslt|
> FADD                                                   | ex1 | ex2 | ex3
> |reslt|
> ST           |AGEN
> |cache|-----------------------------------------------|align|write|
> LOOP         | inc |
>
> LD                 |AGEN |cache|align|reslt|
> LD                 |AGEN |cache|align|reslt|
> FMUL                                 | ex1 | ex2 | ex3 | ex4 |reslt|
> FADD                                                         | ex1 | ex2
> | ex3 |reslt|
> ST                 |AGEN
> |cache|-----------------------------------------------|align|write|
> LOOP               | inc |
>
> This is about as much Out-of-order one gets in a GBOoO machine.
> Andy Glew would say that this is "not that much" out of order.
> Notice that every function unit sees every operation in program
> order and that the only OoO-ness is the latency of calculations.
[...]

I remember some older conversations I had with Andy Glew! He is very
smart, so are you.

On Tue, 19 Dec 2023 03:36:06 +0000, Quadibloc wrote:

> I changed where, in the opcode space, the supplementary memory-reference
> instructions were located. This allowed me to have a few more bits
> available for them.

I've moved them again, making even more space available... because in
my last change, I made the mistake of using the opcode space that I
was already using for block headers. I couldn't reduce the amount of
information in a block header by two bits, by using a combination of
ten bits instead of eight to indicate a block header, so I had to do
my rearranging in this place instead.

John Savard

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On 12/6/23 2:54 AM, Anton Ertl wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>[snip]
>>> One of my professors back in the late 70's was researching
>>> data flow architectures. Perhaps it's time to reconsider the
>>> unit of compute using single instructions, instead providing a
>>> set of hardware 'functions' than can be used in a data flow environment.
>>
>> We already have data-flow microarchitectures since the mid-1990s, with
>> the success of OoO execution. And the "von Neumann" ISAs have proven
>> to be a good and long-term stable interface between software and these
>> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
>> and their microarchitectures turned out to be uncompetetive.
>
>I suspect that a superior interface could be designed which
>exploits diverse locality (i.e., data might naturally be closer to
>some computational resources than to others) and communication
>(and storage) costs and budgets (budgets being related to urgency
>and importance).

There have been a number of attempts to design architectures with more
explicit hardware-oriented features, as well as attempts to design
architectures with more software-oriented features.

On the hardware-oriented side we have seen:

* Explicit fast/small memories that leaves the problem of locality to
software rather than adding the hardware complexity of cache tags
and letting the hardware guess what memory will be accessed in the
future. The only such memories that have succeeded in the long term
are registers; my explanation for the latter is that registers are
useful for scalar variables in programs (and vector/SIMD registers
for temporary storage of pieces of aggregated data).

My explanation for the lack of success of explicit local memory is
that it is too hard for software to manage; dealing with it would be
a cross-cutting concern that would make the software significantly
more complex. Better write software as if there was no cache or
local memory, and let hardware attempt to get good performance out
of it.

* Software prefetch instructions. Ok, we have a cache instead of
explicit local memories, but can't we let software improve the
cache's performace with prefetch hints? I have read some reports
that the experience is that adding such instructions showed
disappointing speedups, and slowdowns also happened. While many
architectures have this feature, it seems to be used little.
Hardware prefetchers seem to do ok, though.

* Distributed memory. This avoids all the problems of cache
consistency, but it requires the programmer to avoid all sharing
(including read-only data and code), and, most importantly, to fit
within its slice of machine. This is acceptable for supercomputing,
but does not fly in general-purpose computing. And even in game
computin, which one might consider to be more supercomputer-like,
the Cell architecture was abandoned in the next generation.

* Weak memory models. Ok, we (hardware designers) have to do cache
consistency, but let's do a shoddy job and shift the problems over
to the software people whom we task with inserting architecturally
meaningless barriers at select places. The great thing about this
is that we can always blame the software people: if the performance
sucks, they have inserted too many barriers; if the program breaks,
they have inserted too few; and if the performance sucks while the
program breaks, well, we can blame them for both, or just shrug and
say that the problem is hard. In any case, the blame is deflected
from us.

One can argue that this particular architectural misfeature has
succeeded: After all, in shared-memory multiprocessors you can buy
today, sequential consistency is nonexistent, and weaker models such
as TSO or even weaker ones dominate.

OTOH, very few programmers program to these weak models. They write
sequential programs, or use libraries/system calls that hide the
horrors of weak consistency behind easier-to-understand but much
slower abstractions.

Isn't that as it should be? Hardware provides some simple, possibly
inconvenient interface, and software abstracts the inconvenience
away; e.g., RISCs provide only a load/store interface, and compilers
translate the stuff programmers write into this interface. The
difference is that with RISCs the result is a least as fast as
architectures that tried to cater more to the programming language,
while I am convinced that hardware where the designers design for
efficient sequential consistency will let programmers write software
that handily outperforms using libraries or system calls on hardware
designed for weaker memory models.

>They also (as I
>understand) lacked value prediction whereas OoO effectively uses
>value prediction for branches.

Branch prediction is branch prediction, value prediction predicts the
values of registers or memory locations; I have seen research about
value prediction maybe 20 years ago, but I am not aware that it has
been productized. IIRC when I asked someone who presented a paper on
value prediction why there should be a significant predictability for
values, the answer was that the values would come from executing along
a mispredicted path: E.g., when an IF is mispredicted, the values of
the code after the ENDIF might still compute to the same values.
However, given the rareness of mispredictions these days, this source
of value prediction probably provides too little benefit to justify
the cost (not to mention Spectre considerations, which came in later).

>While the current interface does allow for significant improvement
>exploiting common behaviors and dynamic microarchitectural
>information, it does not seem (to me) an ideal interface.

I think it is quite remarkable that a sequence of instructions, with
branches and RAM and registers, is what we already have in S/360 (59
years ago) and (I think) in the IBM 704 (69 years ago); I am not
familiar enough with earlier machines or the analytical engine to
comment on them, but this style might be even older. And while the
hardware capabilities have exploded since that time, and performance
characteristics have changed, this style of interface is still doing
well. Even specific instruction sets are doing well: AMD64 with it's
legacy going back to 8086 (45 years ago) and the Datapoint 2200 (53
years ago) competes well with recent architectures such as ARM A64 and
RISC-V. S390x goes back to S/360 (59 years ago); I don't know how
fast it's current implementation is on programs I care about, but I
expect that in an alternative reality where the PC market was based on
S390x, the offerings of Intel and AMD (or whoever would take their
place) would offer similar performance on software I care about as
their AMD64 offerings offer in this reality.

And of course the recent ARM A64 and RISC-V also follow the style
outlined above. RISC-V is even very similar to MIPS (37 years ago),
despite the R2000 having only ~100,000 transistors, and current CPUs
having billions.

>I doubt an alternative interface will be adopted any time soon.
>Even with a better understanding than in the 1970s, the problem is
>not simple and early developments would not be competitive even if
>all the R&D NRE was ignored.

There have been repeated attempts at alternative interfaces, from the
data-flow stuff you mentioned to IA-64, which saw a huge investment
and also had a huge mindshare everywhere. Academia has pursued
alternative programming language concepts (e.g., lazy functional
programming) for many decades, but attempts to cater to alternative
programming languages in architectures have not been successful for
long.

Despite all this work on alternatives ARM A64 and RISC-V are
interfaces that, for the most part work like an IBM 704 or a Commodore
64: RAM actually allows random access (the architecture does not just
not expose caches and hardware prefetchers, but not DRAM bursts, open
DRAM pages and somesuch, either (well, the load/store-pair
instructions of A64 can be attributed to catering to cache line
sizes), and that RAM belongs to the program (virtual memory is usually
transparent to user-level programs).

Anyway, if an alternative interface, closer to what you consider ideal
(what would that be?) has not succeeded, it's not for lack of trying.
And it's also not just because of the network effects: There once was
the 36-bit word-addressed de-facto standard (IBM 704, PDP-6,
Burroughs, and others), but that did not prevent the byte-addressed
32-bit S/360 from succeeding.

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

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On 12/6/23 2:54 AM, Anton Ertl wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>[snip]
>>> One of my professors back in the late 70's was researching
>>> data flow architectures. Perhaps it's time to reconsider the
>>> unit of compute using single instructions, instead providing a
>>> set of hardware 'functions' than can be used in a data flow environment.
>>
>> We already have data-flow microarchitectures since the mid-1990s, with
>> the success of OoO execution. And the "von Neumann" ISAs have proven
>> to be a good and long-term stable interface between software and these
>> data-flow microarchitectures, whereas the data-flow ISAs of the 1970s
>> and their microarchitectures turned out to be uncompetetive.
>
>I suspect that a superior interface could be designed which
>exploits diverse locality (i.e., data might naturally be closer to
>some computational resources than to others) and communication
>(and storage) costs and budgets (budgets being related to urgency
>and importance). I think the original dataflow architectures
>attempted to be very general with significant overhead for
>readiness determination and communication. They also (as I
>understand) lacked value prediction whereas OoO effectively uses
>value prediction for branches.

I would argue that the Cavium coprocessors are data flow at the
level envisioned in the 1970s research. The data (network packets)
are presented (queued) to the appropriate coprocessor as it
flows through the configured set of coprocessors for the data
stream.

On Fri, 10 Nov 2023 22:03:23 +0000, Thomas Koenig wrote:
> Quadibloc <quadibloc@servername.invalid> schrieb:

>> For 32-bit instructions, the only implication is that the first few
>> integer registers would be used as index registers, and the last few
>> would be used as base registers, which is likely to be true in any
>> case.

> This breaks with the central tenet of the /360, the PDP-11,
> the VAX, and all RISC architectures: (Almost) all registers are
> general-purpose registers.

> This would make your ISA very un-S/360-like.

Well, I felt that _some_ compromises had to be made; otherwise,
there was no way instructions with base-index addressing _and_
16-bit displacements would fit into 32 bits.

So this isn't a decision I can reverse. Yes, it has its problems,
but it's an unavoidable result of my goal of combining aspects of
RISC and CISC in a single ISA.

John Savard

On Tue, 05 Dec 2023 11:07:09 +0000, Anton Ertl wrote:

> Quadibloc <quadibloc@servername.invalid> writes:
> [IBM Model 195]
>>Its microarchitecture ended up being, in general terms, copied by the
>>Pentium Pro and the Pentium II.
>
> Not really. The Models 91 and 195 only have OoO for FP, not for
> integers.

As do the Pentium Pro and the Pentium II. (The Motorola 68050 did it
the other way around, only having OoO for integers, and not for FP,
figuring, I guess, that integers are used the most, so this would
create better performance numbers.)

John Savard