[Info-vax] Hard links on VMS ODS5 disks

[Arne Vajhøj]

On 8/29/2023 11:19 AM, John Reagan wrote:
> On Monday, August 28, 2023 at 9:26:19 PM UTC-4, Dan Cross wrote:
>> In article <45fd1f30-55fb-4691... at googlegroups.com>,
>> John Reagan <xyzz... at gmail.com> wrote:
>>> Macro doesn't use the LLVM optimizer (it doesn't use the GEM one either). All the
>>> branching between routines doesn't fit the high-level model.
>>>
>>> Macro does a limited job of pulling address computations out of loops if there are
>>> free registers (and on x86, the answer is "almost never").
>>>
>>> With GEM, AMACRO/IMACRO gets the benefit of GEM's instruction level peephole
>>> optimizer. That doesn't exist in that form for LLVM. So XMACRO today has several
>>> "branches to branches" and is sloppy with x86 condition codes. However, we think
>>> the microarchitecture and predictive execution takes care of those branches to branches
>>> and the like.
>>>
>>> In general Macro-32 code is optimized by the human while typing it in.
>> This begs a question: how useful are those optimizations? I
>> imagine many are based on an execution environment that is not
>> the actual target anymore; is it possible that something that
>> was a clear win on VAX is a pessimization as implemented on
>> x86?
>>
> I was mostly talking about doing things like common sub-expression (computing a value
> once outside of a loop), doing clever shifts vs divide, etc.  For knowing that some VAX
> instructions are "faster" than other VAX instructions stopped being useful when moving
> to Alpha.    For instance, no integer divide on Alpha; no actual divide on Itanium; but both
> kinds of divide on x86.


I think of it like:
* the Macro-32 code ran acceptable fast on a VAX 780
* I don't believe the unoptimized Macro-32
   on Alpha/Itanium/x86-64 could be improved more than x5
* newer systems are at least x1000 faster than a VAX 780
so the absolutely worst case scenario is that the unoptimized
Macro-32 is only x200 faster than on a VAX 780.

I guess we can live with that.  :-)

Arne