[TUHS] Multiflow Compiler

[TUHS] Multiflow Compiler

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

I happened upon
https://old.gustavobarbieri.com.br/trabalhos-universidade/mc722/lowney92multiflow.pdf
and I am curious as to whether any of the original Multiflow compilers
survive.  I had never heard of them before now, but the fact that they were
licensed to so many influential companies makes me think that there might
be folks on this list who know of its history.

-Henry

[-- Attachment #2: Type: text/html, Size: 544 bytes --]

[TUHS] Re: Multiflow Compiler

[Jon Steinhart]

Henry Bent writes:
> I happened upon
> https://old.gustavobarbieri.com.br/trabalhos-universidade/mc722/lowney92multiflow.pdf
> and I am curious as to whether any of the original Multiflow compilers
> survive.  I had never heard of them before now, but the fact that they were
> licensed to so many influential companies makes me think that there might
> be folks on this list who know of its history.
>
> -Henry

Great question.  Unfortunately, Cindy passed away last summer.
I haven't been in touch with John or Ben in decades and don't
know how to reach them.  They used to have a company called
Equator (I think) that continued work on their trace scheduling
compilier after the demise of Multiflow.  I do have a big file
folder with info on the compiler design but I don't think that
I'm free to share it.

Jon

[TUHS] Re: Multiflow Compiler

[Luther Johnson]

You can always read Josh Fisher's book on the "Bulldog" compiler, I
believe he did this work at Yale.

On 04/01/2024 11:53 AM, Jon Steinhart wrote:
> Henry Bent writes:
>> I happened upon
>> https://old.gustavobarbieri.com.br/trabalhos-universidade/mc722/lowney92multiflow.pdf
>> and I am curious as to whether any of the original Multiflow compilers
>> survive.  I had never heard of them before now, but the fact that they were
>> licensed to so many influential companies makes me think that there might
>> be folks on this list who know of its history.
>>
>> -Henry
> Great question.  Unfortunately, Cindy passed away last summer.
> I haven't been in touch with John or Ben in decades and don't
> know how to reach them.  They used to have a company called
> Equator (I think) that continued work on their trace scheduling
> compilier after the demise of Multiflow.  I do have a big file
> folder with info on the compiler design but I don't think that
> I'm free to share it.
>
> Jon
>

[TUHS] Re: Multiflow Compiler

[Lawrence Stewart]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Well some of the authors of the trace scheduling paper from Multiflow, Geoff Lowney, and Bob Nix, wound up at Digital in the early 90’s.  Geoff is now an Intel Fellow, still doing compilers.

-L

> On Apr 1, 2024, at 2:44 PM, Henry Bent <henry.r.bent@gmail.com> wrote:
> 
> I happened upon https://old.gustavobarbieri.com.br/trabalhos-universidade/mc722/lowney92multiflow.pdf and I am curious as to whether any of the original Multiflow compilers survive.  I had never heard of them before now, but the fact that they were licensed to so many influential companies makes me think that there might be folks on this list who know of its history.
> 
> -Henry


[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

[TUHS] Re: Multiflow Compiler

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

The back end (optimizer and code generator) for Intel's current C/C++ and
Fortran compilers uses a modified version of Multiflow IL0 as its
intermediate language.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 286 bytes --]

[TUHS] Re: Multiflow Compiler

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Tue, Apr 2, 2024 at 11:53 AM Paul Winalski <paul.winalski@gmail.com>
wrote:

> The back end (optimizer and code generator) for Intel's current C/C++ and
> Fortran compilers uses a modified version of Multiflow IL0 as its
> intermediate language.
>
> Clem Cole reminds me that the situation has changed since I retired from
Intel in 2016.  Intel has switched to a LLVM-based compiler back end.  The
migration to LLVM was just getting started when I retired.  Intel has been
contributing to LLVM, particularly in the areas of parallelization, loop
transformation, and interprocedural optimization.  Some of this technology
has Multiflow roots.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 1007 bytes --]

[TUHS] Re: Multiflow Compiler

[Paul McJones]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

> You can always read Josh Fisher's book on the "Bulldog" compiler, I
> believe he did this work at Yale.

Are you thinking of John Ellis’s thesis:

Bulldog: A Compiler for VLIW Architectures
John R. Ellis
February 1985
http://www.cs.yale.edu/publications/techreports/tr364.pdf

Fisher was Ellis’s advisor. The thesis was also published in ACM’s Doctoral Dissertation Award:

https://mitpress.mit.edu/9780262050340/bulldog/

I believe Ellis still has a tape with his thesis software on it, but I don’t know if he’s been able to read it.


[-- Attachment #2: Type: text/html, Size: 2376 bytes --]

[TUHS] Re: Multiflow Compiler

[Luther Johnson]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

You are correct. I had (and read !), that book, but I had obviously
forgotten the author. I later worked with someone who also had Josh
Fisher as his advisor, so that's where my lossy memory name substitution
came from. Thank you for the correction !

I enjoyed that book when I read it.

On 04/02/2024 03:55 PM, Paul McJones wrote:
>> You can always read Josh Fisher's book on the "Bulldog" compiler, I
>> believe he did this work at Yale.
>
> Are you thinking of John Ellis’s thesis:
>
>     Bulldog: A Compiler for VLIW Architectures
>
>     John R. Ellis
>     February 1985
>     http://www.cs.yale.edu/publications/techreports/tr364.pdf
>
>
> Fisher was Ellis’s advisor. The thesis was also published in ACM’s
> Doctoral Dissertation Award:
>
>     https://mitpress.mit.edu/9780262050340/bulldog/
>
>
> I believe Ellis still has a tape with his thesis software on it, but I
> don’t know if he’s been able to read it.
>


[-- Attachment #2: Type: text/html, Size: 3691 bytes --]