Has Intel's IA-64 design died the death?

On 12/05/2021 17:32, gareth evans wrote:
> Has Intel's IA-64 design died the death?

The last shipping of an IA-64 processor is July 2021. After that, no
more will be made (according to current plans, anyway). But existing
systems will be in use for many years yet, gradually being replaced by
other processors. (I wonder if there is a definable half-life for
outdated processors?)

In article <s7gtk1$csi$1@dont-email.me>, david.brown@hesbynett.no (David
Brown) wrote:
> On 12/05/2021 17:32, gareth evans wrote:
> > Has Intel's IA-64 design died the death?
> The last shipping of an IA-64 processor is July 2021.

Interestingly, nobody seems to have written an emulator for it. I suppose
there is no nostalgia for it yet.

John

On 2021-05-12, John Dallman wrote:
> In article <s7gtk1$csi$1@dont-email.me>, david.brown@hesbynett.no (David
> Brown) wrote:
>> On 12/05/2021 17:32, gareth evans wrote:
>>> Has Intel's IA-64 design died the death?
>> The last shipping of an IA-64 processor is July 2021.
>
> Interestingly, nobody seems to have written an emulator for it. I suppose
> there is no nostalgia for it yet.
>
> John
>

I wonder how many actually used and enjoyed using the IA-64. I have a
friend who worked on it (not sure which parts), but if I've read him
correctly he wasn't very fond of the design.

/Marcus

According to Marcus <m.delete@this.bitsnbites.eu>:
>I wonder how many actually used and enjoyed using the IA-64. I have a
>friend who worked on it (not sure which parts), but if I've read him
>correctly he wasn't very fond of the design.

VLIW was a good idea in the 1980s but as densities have increased and we can now do in
hardware what VLIW did in software, it has become more trouble than it's worth except
perhaps in some signal processing niches.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> Wrote in message:
> According to Marcus <m.delete@this.bitsnbites.eu>:>I wonder how many actually used and enjoyed using the IA-64. I have a>friend who worked on it (not sure which parts), but if I've read him>correctly he wasn't very fond of the design.VLIW was a good idea in the 1980s but as densities have increased and we can now do inhardware what VLIW did in software, it has become more trouble than it's worth exceptperhaps in some signal processing niches.-- Regards,John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly

That's certainly been the decision of the market, but it's less
clear it was wise. The stuff "we can now do in hardware" happened
at compile time, so less critical in performance. And putting
complexity in hardware makes it harder to correct
errors.

Does anyone think x86 won because it's the ideal ISA?

--

----Android NewsGroup Reader----
http://usenet.sinaapp.com/

John Levine [2021-05-12 20:12:38] wrote:
> According to Marcus <m.delete@this.bitsnbites.eu>:
>>I wonder how many actually used and enjoyed using the IA-64. I have a
>>friend who worked on it (not sure which parts), but if I've read him
>>correctly he wasn't very fond of the design.
> VLIW was a good idea in the 1980s but as densities have increased and we can now do in
> hardware what VLIW did in software, it has become more trouble than it's worth except
> perhaps in some signal processing niches.

I find this answer entertaining because AFAIK the IA64 architecture's
wasn't VLIW at all (tho it was marketed as some kind of successor to the
principles of VLIW).

In retrospect, I wonder what the IA64 architecture had going for it
(other than manpower/money). Or in more constructive terms, from which
aspects of IA64 might future computer architects find good inspirations?
The one feature I remember from it is the idea of "bundling"
instructions such that you can define instructions of funny sizes rather
than being stuck with 16bit, 32bit, ... (it probably wasn't the first
ISA that did that, but it was the first where I saw it).

Stefan

On Wednesday, May 12, 2021 at 3:57:34 PM UTC-5, sarr wrote:
> John Levine <jo...@taugh.com> Wrote in message:
> > According to Marcus <m.de...@this.bitsnbites.eu>:>I wonder how many actually used and enjoyed using the IA-64. I have a>friend who worked on it (not sure which parts), but if I've read him>correctly he wasn't very fond of the design.VLIW was a good idea in the 1980s but as densities have increased and we can now do inhardware what VLIW did in software, it has become more trouble than it's worth exceptperhaps in some signal processing niches.-- Regards,John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly
>
> That's certainly been the decision of the market, but it's less
> clear it was wise. The stuff "we can now do in hardware" happened
> at compile time, so less critical in performance. And putting
> complexity in hardware makes it harder to correct
> errors.
<
Had Itanium had the property that it was faster to design and fabricate that x86, it would have
survived a lot longer. But it had dreadfully slow implementations in calendar time not just in clock
frequencies, and was expensive to boot. What kept it alive was that it used 2× as many pins in
the port to DRAM than x86s, so it had more memory BW and this showed up on certain kinds of
benchmarks.
>
> Does anyone think x86 won because it's the ideal ISA?
<
x86 won because of the amount of cubic dollars that could be spent in design teams and FABs.
>
> --
>
>
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/

In article <s7h71q$76h$1@dont-email.me>, m.delete@this.bitsnbites.eu
(Marcus) wrote:

> I wonder how many actually used and enjoyed using the IA-64. I have
> a friend who worked on it (not sure which parts), but if I've read
> this correctly he wasn't very fond of the design.

I spent more than two years porting libraries to it, which was wasted
effort, since very few applications based on those libraries shipped, and
those that were released were dropped quite quickly.

I have never encountered anyone who was enthusiastic about it who had
done any serious programming on it. I was quite keen at first, but
learned better. My boss at the time's attitude was "It doesn't matter if
it's bad, it will still be a market success because of Intel." That
proved not to be the case, thanks to AMD.

A piece of dialog that one of our managers had with HP:

HP: "You're biased against Itanium!"
Us: "We prefer to think of it as 'well-informed'"

John

On Wednesday, May 12, 2021 at 3:12:40 PM UTC-5, John Levine wrote:
> According to Marcus <m.de...@this.bitsnbites.eu>:
> >I wonder how many actually used and enjoyed using the IA-64. I have a
> >friend who worked on it (not sure which parts), but if I've read him
> >correctly he wasn't very fond of the design.
<
> VLIW was a good idea in the 1980s
<
I question this premise. The best I can say about VLIW is that in the 1980s we did not know
enough about VLIW to state that it was not a good idea. I propose that now we lean heavily
in that direction (not good) hoping that Mill will save VLIW.
<
In before Ivan claims Mill is not VLIW.
<
> but as densities have increased and we can now do in
> hardware what VLIW did in software, it has become more trouble than it's worth except
> perhaps in some signal processing niches.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

In article <jwvsg2rfxz8.fsf-monnier+comp.arch@gnu.org>,
monnier@iro.umontreal.ca (Stefan Monnier) wrote:

> Or in more constructive terms, from which aspects of IA64 might
> future computer architects find good inspirations?

It provides examples of ideas that look clever, but should be avoided.
They include, but are not limited to:

* Being far too complicated overall.
* Excessive use of predicate registers.
* Excessive use of register windowing.
* Modulo-scheduled loops.
* A particular design of self-defeating software-controlled prefetching.
* Having a bulky instruction set, because "RAM is cheap." Cache isn't.
* Relying on the compiler for problems you can't solve in hardware.
* Assuming you can solve long-standing compsci problems with manpower.
* Mismanagement of the software developer programme.

John

On 5/12/2021 3:12 PM, John Levine wrote:
> According to Marcus <m.delete@this.bitsnbites.eu>:
>> I wonder how many actually used and enjoyed using the IA-64. I have a
>> friend who worked on it (not sure which parts), but if I've read him
>> correctly he wasn't very fond of the design.
>
> VLIW was a good idea in the 1980s but as densities have increased and we can now do in
> hardware what VLIW did in software, it has become more trouble than it's worth except
> perhaps in some signal processing niches.
>

It also makes sense on FPGAs, when the main alternatives are
single-issue scalar cores or the occasional in-order superscalar.

I guess there are also some Cortex-M clones for Artix-7 FPGAs, which
generally seem to target 16 .. 25MHz territory.

There is also MicroBlaze, which is basically along similar lines to a
32-bit MIPS variant, typically single-issue, can run at ~ 100MHz on an
Artix-7. Apparently MicrBlaze was derived from the Patterson and
Hennessy DLX ISA.

....

In my case, I have generally ended up stuck at ~ 50MHz.
Doing 75MHz is possible, but performance takes a big hit when one has to
use significantly smaller L1 caches and similar (eg: 2K rather than 16K).

Would likely need to design caches and similar a bit differently if the
goal is to operate at higher clock speeds, eg:
1 or 2K L1's, followed by a combined 16K or 32K "L1.5" cache.
The L1.5 cache could exist between the L1 caches and the TLB;
Would basically work by "intercepting" requests and responses.
Cache Hit: Responds to the request itself;
Cache Miss: Ignore the request, which goes TLB->L2 as usual;
L2 Response: Quietly caches the data for later.

On 5/12/2021 2:33 PM, MitchAlsup wrote:
> On Wednesday, May 12, 2021 at 3:57:34 PM UTC-5, sarr wrote:
>> John Levine <jo...@taugh.com> Wrote in message:
>>> According to Marcus <m.de...@this.bitsnbites.eu>:>I wonder how many actually used and enjoyed using the IA-64. I have a>friend who worked on it (not sure which parts), but if I've read him>correctly he wasn't very fond of the design.VLIW was a good idea in the 1980s but as densities have increased and we can now do inhardware what VLIW did in software, it has become more trouble than it's worth exceptperhaps in some signal processing niches.-- Regards,John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly
>>
>> That's certainly been the decision of the market, but it's less
>> clear it was wise. The stuff "we can now do in hardware" happened
>> at compile time, so less critical in performance. And putting
>> complexity in hardware makes it harder to correct
>> errors.
> <
> Had Itanium had the property that it was faster to design and fabricate that x86, it would have
> survived a lot longer. But it had dreadfully slow implementations in calendar time not just in clock
> frequencies, and was expensive to boot. What kept it alive was that it used 2× as many pins in
> the port to DRAM than x86s, so it had more memory BW and this showed up on certain kinds of
> benchmarks.
>>
>> Does anyone think x86 won because it's the ideal ISA?
> <
> x86 won because of the amount of cubic dollars that could be spent in design teams and FABs.

I think it is more correct to say that those factors prevented it from
losing.

What caused it to win was Microsoft's choice to use it and thus the
availability of software caused it to win initially, and the inertia of
a large software installed base kept it winning over time.

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

On 12/05/2021 22:57, Sarr Blumson wrote:
> John Levine <johnl@taugh.com> Wrote in message:
>> According to Marcus <m.delete@this.bitsnbites.eu>:>I wonder how many actually used and enjoyed using the IA-64. I have a>friend who worked on it (not sure which parts), but if I've read him>correctly he wasn't very fond of the design.VLIW was a good idea in the 1980s but as densities have increased and we can now do inhardware what VLIW did in software, it has become more trouble than it's worth exceptperhaps in some signal processing niches.-- Regards,John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly
>
> That's certainly been the decision of the market, but it's less
> clear it was wise. The stuff "we can now do in hardware" happened
> at compile time, so less critical in performance. And putting
> complexity in hardware makes it harder to correct
> errors.

The trouble was (AFAIUI) that such stuff could not be done at compile
time. IA-64 was EPIC - "Explicitly Parallel". The compiler had to
figure out which instructions could be handled in parallel and put that
in fixed code. That worked well enough for some stuff, but as soon as
there was run-time dependent changes to the code flow (such as an "if"
statement), it got screwed - the ideal set of parallel instructions
changed from those that the compiler had generated. Thus processors
that made these decisions at run-time (super-scaler multi-issue cpus)
gave you more speed for a great deal less money and power.

When the Itanium was being planned, I gather that this was a concern -
but the PHB's in charge thought that by the time the hardware was ready,
the software folk would have made compilers that were more efficient.

>
> Does anyone think x86 won because it's the ideal ISA?
>

Modern x86 processors are amazing engineering and fantastic
implementations of a seriously poor ISA that was outdated when the first
8088 was drawn up. They are proof that you /can/ polish a shite.

The x86 ISA is popular because it is popular - it is stuck in a positive
feedback loop.

John Dallman [2021-05-12 23:06:00] wrote:
> monnier@iro.umontreal.ca (Stefan Monnier) wrote:
>> Or in more constructive terms, from which aspects of IA64 might
>> future computer architects find good inspirations?
> It provides examples of ideas that look clever, but should be avoided.

Yes, most of these are pretty famous by now, which is why I think it'd
be fun to try and look on the positive side for a change ;-)

Stefan

MitchAlsup wrote:
> On Wednesday, May 12, 2021 at 3:57:34 PM UTC-5, sarr wrote:
>> John Levine <jo...@taugh.com> Wrote in message:
>>> According to Marcus <m.de...@this.bitsnbites.eu>:>I wonder how many actually used and enjoyed using the IA-64. I have a>friend who worked on it (not sure which parts), but if I've read him>correctly he wasn't very fond of the design.VLIW was a good idea in the 1980s but as densities have increased and we can now do inhardware what VLIW did in software, it has become more trouble than it's worth exceptperhaps in some signal processing niches.-- Regards,John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly
>> That's certainly been the decision of the market, but it's less
>> clear it was wise. The stuff "we can now do in hardware" happened
>> at compile time, so less critical in performance. And putting
>> complexity in hardware makes it harder to correct
>> errors.
> <
> Had Itanium had the property that it was faster to design and fabricate that x86, it would have
> survived a lot longer. But it had dreadfully slow implementations in calendar time not just in clock
> frequencies, and was expensive to boot. What kept it alive was that it used 2× as many pins in
> the port to DRAM than x86s, so it had more memory BW and this showed up on certain kinds of
> benchmarks.
>> Does anyone think x86 won because it's the ideal ISA?
> <
> x86 won because of the amount of cubic dollars that could be spent in design teams and FABs.

A lack of overarching design philosophy allows x86/x64 to
quickly adapt to changing current market conditions.

Cubic dollars allows it to drag previous non-philosophy based
decisions with it into the present.

On 5/12/2021 2:37 PM, MitchAlsup wrote:
> On Wednesday, May 12, 2021 at 3:12:40 PM UTC-5, John Levine wrote:
>> According to Marcus <m.de...@this.bitsnbites.eu>:
>>> I wonder how many actually used and enjoyed using the IA-64. I have a
>>> friend who worked on it (not sure which parts), but if I've read him
>>> correctly he wasn't very fond of the design.
> <
>> VLIW was a good idea in the 1980s
> <
> I question this premise. The best I can say about VLIW is that in the 1980s we did not know
> enough about VLIW to state that it was not a good idea. I propose that now we lean heavily
> in that direction (not good) hoping that Mill will save VLIW.
> <
> In before Ivan claims Mill is not VLIW.
> <

<rising to bait>

What's a VLIW? - rigorous definition please :-)

Some people make it synonymous with "wide issue", i.e. when instructions
are issued in groups that are asserted to be free of inter-instruction
dependencies. By that definition Mitch's is a pre-parse feeding a VLIW,
which is an idea I think he would choke on. That would also make IA64
and Mill also be VLIWs, which I feel is an unhelpful blending of
distinct architectural choices.

I feel that a finer division based on the retire semantics is useful.
There seem to be three categories: 1) everything retires a statically
known number of cycles after issue, and other bundles may issue in the
time between issue and retire; 2) everything retires as soon as
possible, but nothing else issues or enters execution until all the
instructions of the bundle have retired; 3) everything retires as soon
as possible, and instructions from subsequent bundles issue together but
do not enter execution until their dependencies retire. Thus with
respect to retire semantics Mill=classic VLIW=1, IA64=2, and Mitch=3.

However, while Mill retires like a VLIW, it does not issue like one.
Instead of bundles issuing one by one in order, Mill issue is temporally
interleaved (in a statically schedulable way) just as Mill retire is
interleaved. This is, Mill bundles are an encoding notion, not a
temporal notion; that's true for Mitch too, except Mitch's bundle is in
the trace cache and Mill's are in DRAM, and Mitch's use dynamic
scheduling of execution and Mill uses static.

If Mill didn't have phasing then I too would call it a VLIW. But it does
have phasing, and calling it a VLIW confuses it with true VLIW
architectures like Trimedia, Texas Instruments C64, and Hexagon, which
are very different from Mill in both design and implementation.

On 5/12/2021 6:28 PM, Ivan Godard wrote:
> On 5/12/2021 2:37 PM, MitchAlsup wrote:
>> On Wednesday, May 12, 2021 at 3:12:40 PM UTC-5, John Levine wrote:
>>> According to Marcus <m.de...@this.bitsnbites.eu>:
>>>> I wonder how many actually used and enjoyed using the IA-64. I have a
>>>> friend who worked on it (not sure which parts), but if I've read him
>>>> correctly he wasn't very fond of the design.
>> <
>>> VLIW was a good idea in the 1980s
>> <
>> I question this premise. The best I can say about VLIW is that in the
>> 1980s we did not know
>> enough about VLIW to state that it was not a good idea. I propose that
>> now we lean heavily
>> in that direction (not good) hoping that Mill will save VLIW.
>> <
>> In before Ivan claims Mill is not VLIW.
>> <
>
> <rising to bait>
>
> What's a VLIW? - rigorous definition please :-)
>
> Some people make it synonymous with "wide issue", i.e. when instructions
> are issued in groups that are asserted to be free of inter-instruction
> dependencies. By that definition Mitch's is a pre-parse feeding a VLIW,
> which is an idea I think he would choke on. That would also make IA64
> and Mill also be VLIWs, which I feel is an unhelpful blending of
> distinct architectural choices.
>
> I feel that a finer division based on the retire semantics is useful.
> There seem to be three categories: 1) everything retires a statically
> known number of cycles after issue, and other bundles may issue in the
> time between issue and retire; 2) everything retires as soon as
> possible, but nothing else issues or enters execution until all the
> instructions of the bundle have retired; 3) everything retires as soon
> as possible, and instructions from subsequent bundles issue together but
> do not enter execution until their dependencies retire. Thus with
> respect to retire semantics Mill=classic VLIW=1, IA64=2, and Mitch=3.
>

If I understand this, BJX2 would be 2 here.

Generally, writeback happens after a fixed dependency, but the next
bundle may begin executing as soon as there are no longer any interlock
dependencies, which depends on the latency of each instruction. Prior to
write-back, these is forwarding.

Or, the latency of the longest instruction for which an interlock occurs.

AFAIK, some classic VLIW machines don't have interlocks or forwarding,
so if one tries to use a result before writeback happens, they will just
get a stale value.

For adverse cases, one might need to emit bundles full of NOPs.

I didn't really want to go this route in my ISA though, so I felt that
interlocks were kind of a "necessary evil" for general usability.
Though, if one can organize instructions to minimize triggering
interlocks, this is better.

....

> However, while Mill retires like a VLIW, it does not issue like one.
> Instead of bundles issuing one by one in order, Mill issue is temporally
> interleaved (in a statically schedulable way) just as Mill retire is
> interleaved. This is, Mill bundles are an encoding notion, not a
> temporal notion; that's true for Mitch too, except Mitch's bundle is in
> the trace cache and Mill's are in DRAM, and Mitch's use dynamic
> scheduling of execution and Mill uses static.
>
> If Mill didn't have phasing then I too would call it a VLIW. But it does
> have phasing, and calling it a VLIW confuses it with true VLIW
> architectures like Trimedia, Texas Instruments C64, and Hexagon, which
> are very different from Mill in both design and implementation.
>
>

Hmm...

On Wednesday, May 12, 2021 at 6:28:02 PM UTC-5, Ivan Godard wrote:
> On 5/12/2021 2:37 PM, MitchAlsup wrote:
> > On Wednesday, May 12, 2021 at 3:12:40 PM UTC-5, John Levine wrote:
> >> According to Marcus <m.de...@this.bitsnbites.eu>:
> >>> I wonder how many actually used and enjoyed using the IA-64. I have a
> >>> friend who worked on it (not sure which parts), but if I've read him
> >>> correctly he wasn't very fond of the design.
> > <
> >> VLIW was a good idea in the 1980s
> > <
> > I question this premise. The best I can say about VLIW is that in the 1980s we did not know
> > enough about VLIW to state that it was not a good idea. I propose that now we lean heavily
> > in that direction (not good) hoping that Mill will save VLIW.
> > <
> > In before Ivan claims Mill is not VLIW.
> > <
> <rising to bait>
<
<you certainly did !!
>
> What's a VLIW? - rigorous definition please :-)
>
> Some people make it synonymous with "wide issue", i.e. when instructions
> are issued in groups that are asserted to be free of inter-instruction
> dependencies. By that definition Mitch's is a pre-parse feeding a VLIW,
> which is an idea I think he would choke on. That would also make IA64
> and Mill also be VLIWs, which I feel is an unhelpful blending of
> distinct architectural choices.
<
No, MILL is not VLIW because it has the underlying flavor of decoupled
execute and control-flow,
<
Secondly, Mill in not VLIW of the belt, mechanism which shuffles belt
locations to the stack (and back) at subroutine and block boundaries.
<
I could probably think of a few more given time.
<
The only thing that really makes Mill smell VLIW is the "compiler does
all the scheduling thing".
>
> I feel that a finer division based on the retire semantics is useful.
> There seem to be three categories: 1) everything retires a statically
> known number of cycles after issue, and other bundles may issue in the
> time between issue and retire; 2) everything retires as soon as
> possible, but nothing else issues or enters execution until all the
> instructions of the bundle have retired; 3) everything retires as soon
> as possible, and instructions from subsequent bundles issue together but
> do not enter execution until their dependencies retire. Thus with
> respect to retire semantics Mill=classic VLIW=1, IA64=2, and Mitch=3.
<
Mitch also supports the notion that calculations begin as soon as
RAW hazards resolve and result deliver can begin as soon as WAR
hazards resolve. {I.e., Scoreboard} Mitch = {3 and 4}
<
In both cases, packets of instruction enter and retire from execution as
packetized.
>
> However, while Mill retires like a VLIW, it does not issue like one.
> Instead of bundles issuing one by one in order, Mill issue is temporally
> interleaved (in a statically schedulable way) just as Mill retire is
> interleaved. This is, Mill bundles are an encoding notion, not a
> temporal notion; that's true for Mitch too, except Mitch's bundle is in
> the trace cache and Mill's are in DRAM, and Mitch's use dynamic
> scheduling of execution and Mill uses static.
<
S/trace/packet/
>
> If Mill didn't have phasing then I too would call it a VLIW. But it does
> have phasing, and calling it a VLIW confuses it with true VLIW
> architectures like Trimedia, Texas Instruments C64, and Hexagon, which
> are very different from Mill in both design and implementation.

On Wednesday, May 12, 2021 at 7:11:55 PM UTC-5, BGB wrote:
> On 5/12/2021 6:28 PM, Ivan Godard wrote:
> > On 5/12/2021 2:37 PM, MitchAlsup wrote:
> >> On Wednesday, May 12, 2021 at 3:12:40 PM UTC-5, John Levine wrote:
> >>> According to Marcus <m.de...@this.bitsnbites.eu>:
> >>>> I wonder how many actually used and enjoyed using the IA-64. I have a
> >>>> friend who worked on it (not sure which parts), but if I've read him
> >>>> correctly he wasn't very fond of the design.
> >> <
> >>> VLIW was a good idea in the 1980s
> >> <
> >> I question this premise. The best I can say about VLIW is that in the
> >> 1980s we did not know
> >> enough about VLIW to state that it was not a good idea. I propose that
> >> now we lean heavily
> >> in that direction (not good) hoping that Mill will save VLIW.
> >> <
> >> In before Ivan claims Mill is not VLIW.
> >> <
> >
> > <rising to bait>
> >
> > What's a VLIW? - rigorous definition please :-)
> >
> > Some people make it synonymous with "wide issue", i.e. when instructions
> > are issued in groups that are asserted to be free of inter-instruction
> > dependencies. By that definition Mitch's is a pre-parse feeding a VLIW,
> > which is an idea I think he would choke on. That would also make IA64
> > and Mill also be VLIWs, which I feel is an unhelpful blending of
> > distinct architectural choices.
> >
> > I feel that a finer division based on the retire semantics is useful.
> > There seem to be three categories: 1) everything retires a statically
> > known number of cycles after issue, and other bundles may issue in the
> > time between issue and retire; 2) everything retires as soon as
> > possible, but nothing else issues or enters execution until all the
> > instructions of the bundle have retired; 3) everything retires as soon
> > as possible, and instructions from subsequent bundles issue together but
> > do not enter execution until their dependencies retire. Thus with
> > respect to retire semantics Mill=classic VLIW=1, IA64=2, and Mitch=3.
> >
> If I understand this, BJX2 would be 2 here.
>
> Generally, writeback happens after a fixed dependency, but the next
> bundle may begin executing as soon as there are no longer any interlock
> dependencies, which depends on the latency of each instruction. Prior to
> write-back, these is forwarding.
<
With interlocks, one can make "early out" function units, so IDIV can
special case 1<<k divisors and deliver a result in 3-ish cycles rather than
64 DIV {2,3,4} cycles. Or FDIV with a fraction of 0 but a normalized number.
<
Notice that a cache is simply an early out memory access !
>
> Or, the latency of the longest instruction for which an interlock occurs.
>
>
> AFAIK, some classic VLIW machines don't have interlocks or forwarding,
> so if one tries to use a result before writeback happens, they will just
> get a stale value.
<
I actually used this semantic in some PDP-40 microcode where I was
microcoding the PDP-11/45 FP operations in the writable control store
of the PDP-11/40 we had at CMU.
>
> For adverse cases, one might need to emit bundles full of NOPs.
>
>
> I didn't really want to go this route in my ISA though, so I felt that
> interlocks were kind of a "necessary evil" for general usability.
<
Interlocks preserve you ability to make other implementations without
needing specializers (ala Mill).
<
> Though, if one can organize instructions to minimize triggering
> interlocks, this is better.
<
Yes, have but do not use.
>
> ...
> > However, while Mill retires like a VLIW, it does not issue like one.
> > Instead of bundles issuing one by one in order, Mill issue is temporally
> > interleaved (in a statically schedulable way) just as Mill retire is
> > interleaved. This is, Mill bundles are an encoding notion, not a
> > temporal notion; that's true for Mitch too, except Mitch's bundle is in
> > the trace cache and Mill's are in DRAM, and Mitch's use dynamic
> > scheduling of execution and Mill uses static.
> >
> > If Mill didn't have phasing then I too would call it a VLIW. But it does
> > have phasing, and calling it a VLIW confuses it with true VLIW
> > architectures like Trimedia, Texas Instruments C64, and Hexagon, which
> > are very different from Mill in both design and implementation.
> >
> >
> Hmm...

On Wednesday, May 12, 2021 at 2:12:40 PM UTC-6, John Levine wrote:

> VLIW was a good idea in the 1980s but as densities have increased and we can now do in
> hardware what VLIW did in software, it has become more trouble than it's worth except
> perhaps in some signal processing niches.

But if that's true... then how is it that these increased densities haven't prevented Apple's
M1 chip from outperforming x86 chips, thus showing that RISC has genuine advantages?

Of course, that may be comparing apples and oranges. The complexity of the x86 instruction
set versus RISC is not necessary, and brings no direct benefits to offset the burden it
imposes... and, so, it can't be compared to spending transistors on out-of-order hardware,
which does do something useful, versus trying to do it more simply with VLIW.

John Savard

On Wednesday, May 12, 2021 at 3:29:36 PM UTC-6, Stefan Monnier wrote:

> I find this answer entertaining because AFAIK the IA64 architecture's
> wasn't VLIW at all (tho it was marketed as some kind of successor to the
> principles of VLIW).

The Itanium may not have been a "true" VLIW processor.

But like those which are acknowledged as VLIW, it explicitly indicated
which of the three component instructions could be executed in
parallel.

Of course, three is smaller than eight, so perhaps the Itanium was just
a LIW processor.

John Savard

On Wednesday, May 12, 2021 at 3:37:10 PM UTC-6, MitchAlsup wrote:
> I propose that now we lean heavily
> in that direction (not good) hoping that Mill will save VLIW.

> In before Ivan claims Mill is not VLIW.

You're both right.

The Mill clearly doesn't *have* long instruction words, so it can't
be VLIW.

But *like* VLIW, it has an architecture designed so as to allow
the instruction stream to specify things that would have to be
generated by out-of-order logic in a conventional architecture.

The difference is that it doesn't use a giant set of registers to
achieve this, instead it uses its "belt".

John Savard

According to Ivan Godard <ivan@millcomputing.com>:
>What's a VLIW? - rigorous definition please :-)

Josh said it was a combination of wide issue and speculative execution,
with the instructions commanding specific execution units. The compiler
can unwind loops and do trace scheduling to keep lots of parallel units
busy. Speculative execution let it recover from over-eager unwinding
or tracing.

The Multiflow machine, at least, worked great on programs with regular
memory access patterns so it could send multiple memory requests in parallel
to different memory banks. It worked a lot worse if it couldn't tell at
compile time whether references would be to the same or different banks;
that's a place where hardware scheduling using the actual runtime address
data works a lot better.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

> What's a VLIW? - rigorous definition please :-)

I think I'd define it as "wide-issue + static scheduling" and for that
reason I consider the Mill as a sort of VLIW.

> If Mill didn't have phasing then I too would call it a VLIW. But it does
> have phasing, and calling it a VLIW confuses it with true VLIW architectures
> like Trimedia, Texas Instruments C64, and Hexagon, which are very different
> from Mill in both design and implementation.

Clearly phasing makes it different from the previous VLIWs, but that's
not enough to make it "non-VLIW" for me. It just means it's
a fancier VLIW, just like the "split instruction stream" doesn't make it
"non-VLIW".

Stefan