On 10/6/23 2:29 PM, Dave Froble wrote:
> On 10/6/2023 2:39 PM, Chris Townley wrote:
>> On 06/10/2023 19:12, Craig A. Berry wrote:
>>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>>>
>>>> <snip>
>>>>> First we need the native compilers. Cross compilers are
>>>>> not good enough. VMS tradition, confidence in VMS x86-64
>>>>> and the problem with relying on a dead platform Itanium
>>>>> makes native compilers a must.
>>>> <snip>
>>>>> The first is a must. How good the reasons really are does
>>>>> not matter - it is a must have. And luckily we now have
>>>>> 5 out of 6!
>>>>>
>>>>
>>>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
>>>> outstanding.
>>>>
>>>> What about Python and Java?
>>>
>>> Java is available on x86, not sure about Python.
>>>
>>>> and of course LSE
>>>
>>> DECSET has been available for a year and a half at least.
>>
>> But that excluded LSE
>>
>
> Don't really know, but, doesn't LSE depend upon the compilers?
>

I think it depends on compiler listings and compiler messages that look
exactly like they always have.

On 10/6/2023 3:58 PM, Craig A. Berry wrote:> On 10/6/23 2:29 PM, Dave
Froble wrote:
>> On 10/6/2023 2:39 PM, Chris Townley wrote:
>>> On 06/10/2023 19:12, Craig A. Berry wrote:
>>>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>>>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>>>>
>>>>> <snip>
>>>>>> First we need the native compilers. Cross compilers are
>>>>>> not good enough. VMS tradition, confidence in VMS x86-64
>>>>>> and the problem with relying on a dead platform Itanium
>>>>>> makes native compilers a must.
>>>>> <snip>
>>>>>> The first is a must. How good the reasons really are does
>>>>>> not matter - it is a must have. And luckily we now have
>>>>>> 5 out of 6!
>>>>>>
>>>>>
>>>>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
>>>>> outstanding.
>>>>>
>>>>> What about Python and Java?
>>>>
>>>> Java is available on x86, not sure about Python.
>>>>
>>>>> and of course LSE
>>>>
>>>> DECSET has been available for a year and a half at least.
>>>
>>> But that excluded LSE
>>>
>>
>> Don't really know, but, doesn't LSE depend upon the compilers?
>
> I think it depends on compiler listings and compiler messages that look
> exactly like they always have.

Getting LSE for Fortran, Cobol, Pascal, Basic and C working
should not be bad, but I suspect that there will be a lot
of work for C++ - the C++ language LSE on Itanium understands
and the C++ language LSE will need to understand on x86-64
are quite different.

Arne

On 10/6/2023 3:29 PM, Dave Froble wrote:

> Don't really know, but, doesn't LSE depend upon the compilers?

No, the holdup is that I need to fix a few bugs before it can be released.

Other things are slightly higher in priority, but it's 2nd or 3rd on the list.

--
-- Rob

On 06/10/2023 20:10, Craig A. Berry wrote:
>
> On 10/6/23 1:39 PM, Chris Townley wrote:
>> On 06/10/2023 19:12, Craig A. Berry wrote:
>>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>>> On 06/10/2023 01:44, Arne Vajhøj wrote:
>>>>
>>>> <snip>
>>>>> First we need the native compilers. Cross compilers are
>>>>> not good enough. VMS tradition, confidence in VMS x86-64
>>>>> and the problem with relying on a dead platform Itanium
>>>>> makes native compilers a must.
>>>> <snip>
>>>>> The first is a must. How good the reasons really are does
>>>>> not matter - it is a must have. And luckily we now have
>>>>> 5 out of 6!
>>>>>
>>>>
>>>> Presumably you mean C, C++, Cobol, Fortran & Pascal, with Basic
>>>> outstanding.
>>>>
>>>> What about Python and Java?
>>>
>>> Java is available on x86, not sure about Python.
>>>
>>>> and of course LSE
>>>
>>> DECSET has been available for a year and a half at least.
>>
>> But that excluded LSE
>
> Ah, sorry. I forgot about that.  I'm pretty sure the VMS IDE for VSCode
> is available for anyone interested in doing old things in a new way.

I cannot stand VSCODE. There are many good PC based editors, but I used
LSE for well over 20 years, and it works.

--
Chris

On 06/10/2023 22:12, Robert A. Brooks wrote:
> On 10/6/2023 3:29 PM, Dave Froble wrote:
>
>> Don't really know, but, doesn't LSE depend upon the compilers?
>
> No, the holdup is that I need to fix a few bugs before it can be released.
>
> Other things are slightly higher in priority, but it's 2nd or 3rd on the
> list.
>

That sounds brilliant, thank you

--
Chris

On 10/6/2023 6:41 PM, Chris Townley wrote:
> On 06/10/2023 20:10, Craig A. Berry wrote:
>> On 10/6/23 1:39 PM, Chris Townley wrote:
>>> On 06/10/2023 19:12, Craig A. Berry wrote:
>>>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>>>> and of course LSE
>>>>
>>>> DECSET has been available for a year and a half at least.
>>>
>>> But that excluded LSE
>>
>> Ah, sorry. I forgot about that.  I'm pretty sure the VMS IDE for VSCode
>> is available for anyone interested in doing old things in a new way.
>
> I cannot stand VSCODE. There are many good PC based editors, but I used
> LSE for well over 20 years, and it works.

Most people have preferences for editors and IDE's.

VS Code is probably the worlds most widely used IDE / developer editor,
but that does not mean that all developers like it.

You don't like it. I don't like it.

But when VSI had to decide on something to base VMS IDE
on then VS Code is a reasonable choice.

Arne

On 07/10/2023 17:43, Arne Vajhøj wrote:
> On 10/6/2023 6:41 PM, Chris Townley wrote:
>> On 06/10/2023 20:10, Craig A. Berry wrote:
>>> On 10/6/23 1:39 PM, Chris Townley wrote:
>>>> On 06/10/2023 19:12, Craig A. Berry wrote:
>>>>> On 10/6/23 12:06 PM, Chris Townley wrote:
>>>>>> and of course LSE
>>>>>
>>>>> DECSET has been available for a year and a half at least.
>>>>
>>>> But that excluded LSE
>>>
>>> Ah, sorry. I forgot about that.  I'm pretty sure the VMS IDE for VSCode
>>> is available for anyone interested in doing old things in a new way.
>>
>> I cannot stand VSCODE. There are many good PC based editors, but I
>> used LSE for well over 20 years, and it works.
>
> Most people have preferences for editors and IDE's.
>
> VS Code is probably the worlds most widely used IDE / developer editor,
> but that does not mean that all developers like it.
>
> You don't like it. I don't like it.
>
> But when VSI had to decide on something to base VMS IDE
> on then VS Code is a reasonable choice.
>
> Arne
>

I wouldn't disagree, but couldn't they give option for other editors at
the front?

--
Chris

In article <ufnla0$16vim$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>[snip]
>The second I don't see a big need for. And that is where
>I have disagreed with you. VMS users don't really
>care what language VMS is coded in and where it was compiled -
>they just want something that works. And generally 9.2-1
>works great (*).

The specific may be true, but the general is not. Lots of users
care very much how their OS is compiled: they want hermetic,
repeatable builds where binary artifacts can be traced back to
specific source revisions and compiler binaries.

>Sure building VMS with native compilers may give a little
>performance boost, but I don't see that as something causing
>anyone to delay their port. It is still fast enough.

I don't see any reason why a native compiler would give a
performance boost versus a cross-compiler. Optimization passes,
instruction selection, even linking are all just running
programs: read some input, do some computation, write some
output. Where that program runs has little, if any, impact on
performance of the generated code.

Perhaps you mean "performance boost" in terms of the _process_
of building VMS?

- Dan C.

On 10/9/2023 4:23 PM, Dan Cross wrote:
> In article <ufnla0$16vim$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> [snip]
>> The second I don't see a big need for. And that is where
>> I have disagreed with you. VMS users don't really
>> care what language VMS is coded in and where it was compiled -
>> they just want something that works. And generally 9.2-1
>> works great (*).
>
> The specific may be true, but the general is not. Lots of users
> care very much how their OS is compiled: they want hermetic,
> repeatable builds where binary artifacts can be traced back to
> specific source revisions and compiler binaries.

I am pretty sure that 99.9% does not know anything about that.

But anyway the cross-compilers are just as traceable as
the native compilers.

>> Sure building VMS with native compilers may give a little
>> performance boost, but I don't see that as something causing
>> anyone to delay their port. It is still fast enough.
>
> I don't see any reason why a native compiler would give a
> performance boost versus a cross-compiler. Optimization passes,
> instruction selection, even linking are all just running
> programs: read some input, do some computation, write some
> output. Where that program runs has little, if any, impact on
> performance of the generated code.

VSI has stated that the cross compilers on Itanium does
not optimize.

Arne

In article <ug1o38$3sk8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 10/9/2023 4:23 PM, Dan Cross wrote:
>> In article <ufnla0$16vim$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> [snip]
>>> The second I don't see a big need for. And that is where
>>> I have disagreed with you. VMS users don't really
>>> care what language VMS is coded in and where it was compiled -
>>> they just want something that works. And generally 9.2-1
>>> works great (*).
>>
>> The specific may be true, but the general is not. Lots of users
>> care very much how their OS is compiled: they want hermetic,
>> repeatable builds where binary artifacts can be traced back to
>> specific source revisions and compiler binaries.
>
>I am pretty sure that 99.9% does not know anything about that.

I believe that you are pretty sure of that.

>But anyway the cross-compilers are just as traceable as
>the native compilers.

I never said that they were not.

>>> Sure building VMS with native compilers may give a little
>>> performance boost, but I don't see that as something causing
>>> anyone to delay their port. It is still fast enough.
>>
>> I don't see any reason why a native compiler would give a
>> performance boost versus a cross-compiler. Optimization passes,
>> instruction selection, even linking are all just running
>> programs: read some input, do some computation, write some
>> output. Where that program runs has little, if any, impact on
>> performance of the generated code.
>
>VSI has stated that the cross compilers on Itanium does
>not optimize.

Sounds like an implementation detail.

There is nothing structurally preventing a cross-compiler from
implementing optimization. Of course, if one is trying to focus
on native bring-up of a compiler one may not wish to do so, but
that's a different matter.

- Dan C.

On Monday, October 9, 2023 at 4:41:29 PM UTC-4, Dan Cross wrote:
> In article <ug1o38$3sk8$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >On 10/9/2023 4:23 PM, Dan Cross wrote:
> >> In article <ufnla0$16vim$1...@dont-email.me>,
> >> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> [snip]
> >>> The second I don't see a big need for. And that is where
> >>> I have disagreed with you. VMS users don't really
> >>> care what language VMS is coded in and where it was compiled -
> >>> they just want something that works. And generally 9.2-1
> >>> works great (*).
> >>
> >> The specific may be true, but the general is not. Lots of users
> >> care very much how their OS is compiled: they want hermetic,
> >> repeatable builds where binary artifacts can be traced back to
> >> specific source revisions and compiler binaries.
> >
> >I am pretty sure that 99.9% does not know anything about that.
> I believe that you are pretty sure of that.
> >But anyway the cross-compilers are just as traceable as
> >the native compilers.
> I never said that they were not.
> >>> Sure building VMS with native compilers may give a little
> >>> performance boost, but I don't see that as something causing
> >>> anyone to delay their port. It is still fast enough.
> >>
> >> I don't see any reason why a native compiler would give a
> >> performance boost versus a cross-compiler. Optimization passes,
> >> instruction selection, even linking are all just running
> >> programs: read some input, do some computation, write some
> >> output. Where that program runs has little, if any, impact on
> >> performance of the generated code.
> >
> >VSI has stated that the cross compilers on Itanium does
> >not optimize.
> Sounds like an implementation detail.
>
> There is nothing structurally preventing a cross-compiler from
> implementing optimization. Of course, if one is trying to focus
> on native bring-up of a compiler one may not wish to do so, but
> that's a different matter.
>
> - Dan C.
The VAX-hosted/Alpha-targetted cross-compilers did many of the same optimizations as the eventual native Alpha compilers but some of the compile-time expression optimizations had to be pushed to run-time since VAX doesn't do IEEE math and is only 32-bits (we could have dealt with it but chose not to with only BLISS-32 to work from)

The Alpha-hosted/Itanium-targetted cross-compilers did all of the same optimizations and the eventual native Itanium compilers.

The Itanium-hosted/x86-targetted cross-compilers are no optimize since I couldn't get the current Itanuim C++ compiler to build the LLVM 3.4.2 optimization passes. I spent a week or so playing around and "decided" that the Itanium compiler (or the STL) isn't quite C++03. Since we didn't need the optimizer to boot (and single stepping thru optimized code would be a pain), I just didn't bother. The native compilers are using a much newer version of LLVM and optimizer that was bootstrapped from clang/LLVM on a Linux box.. [Yes, I know of the ancient LLVM target for Itanium but didn't want to stick my hand into those old things just to get an optimizer].

So how much would the system speed up when compiled with optimized compilers? Good question. The Macro compiler generates "good" code with the cross-compiler since we don't use the LLVM optimizer at all. We generate direct x86 code from VAX code. From LLVM's point of view XMACRO is an assembler (which it actually is). So we're talking C and BLISS code that would see an "improvement". From what I can tell with some visual examinations, I see better stack usage. G2L generates lots of temporaries all of which end up on the stack in non-optimized code. With the optimizer, the lifetime analysis shortens/overlaps the stack usage. The code itself is somewhat tighter but with all crazy things done at the micro-architecture level, I'm not sure of the real benefit. The x86 "instructions" are taken apart by the chip and executed on whatever functional units are present. Modern x86 chips have 100s of actual registers inside. I consider the x86 "instruction set" to just be another abstraction. It is turtles all the way down.

In article <5487193e-262c-46b8-a46c-d3ee7e2c35fbn@googlegroups.com>,
John Reagan <xyzzy1959@gmail.com> wrote:
>On Monday, October 9, 2023 at 4:41:29 PM UTC-4, Dan Cross wrote:
>> In article <ug1o38$3sk8$1...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> >VSI has stated that the cross compilers on Itanium does
>> >not optimize.
>>
>> Sounds like an implementation detail.
>>
>> There is nothing structurally preventing a cross-compiler from
>> implementing optimization. Of course, if one is trying to focus
>> on native bring-up of a compiler one may not wish to do so, but
>> that's a different matter.
>
>The VAX-hosted/Alpha-targetted cross-compilers did many of the same
>optimizations as the eventual native Alpha compilers but some of the
>compile-time expression optimizations had to be pushed to run-time
>since VAX doesn't do IEEE math and is only 32-bits (we could have dealt
>with it but chose not to with only BLISS-32 to work from)
>
>The Alpha-hosted/Itanium-targetted cross-compilers did all of the
>same optimizations and the eventual native Itanium compilers.
>
>The Itanium-hosted/x86-targetted cross-compilers are no optimize since
>I couldn't get the current Itanuim C++ compiler to build the LLVM 3.4.2
>optimization passes. I spent a week or so playing around and "decided"
>that the Itanium compiler (or the STL) isn't quite C++03. Since we
>didn't need the optimizer to boot (and single stepping thru optimized
>code would be a pain), I just didn't bother. The native compilers are
>using a much newer version of LLVM and optimizer that was bootstrapped
>from clang/LLVM on a Linux box. [Yes, I know of the ancient LLVM
>target for Itanium but didn't want to stick my hand into those old
>things just to get an optimizer].

Thanks, this is close to what I suspected the real reason for
not optimizing in the cross-compilers was.

>So how much would the system speed up when compiled with optimized
>compilers? Good question. The Macro compiler generates "good" code
>with the cross-compiler since we don't use the LLVM optimizer at all.
>We generate direct x86 code from VAX code. From LLVM's point of view
>XMACRO is an assembler (which it actually is). So we're talking C and
>BLISS code that would see an "improvement". From what I can tell with
>some visual examinations, I see better stack usage. G2L generates lots
>of temporaries all of which end up on the stack in non-optimized code.
>With the optimizer, the lifetime analysis shortens/overlaps the stack
>usage. The code itself is somewhat tighter but with all crazy things
>done at the micro-architecture level, I'm not sure of the real benefit.
>The x86 "instructions" are taken apart by the chip and executed on
>whatever functional units are present. Modern x86 chips have 100s of
>actual registers inside. I consider the x86 "instruction set" to just
>be another abstraction. It is turtles all the way down.

One of the effects we observed when I was working on search
infrastructure at Google was that the x86 instruction encoding
(which, as you note, is basically a P-code around the underlying
microarch) can be very dense, which can yield good icache
utilization, which can be a major win. That is, we saw a direct
correlation between icache hit-rate and execution times.

I've observed that LLVM is pretty good at lowering to relatively
short instruction sequences when aggressively optimized, which
can be an overall win as the probability that any given sequence
of instructions is in the cache is higher.

I'd be curious about observed performance deltas if you all have
numbers to share?

- Dan C.