[Info-vax] Hard links on VMS ODS5 disks

[Dan Cross]

In article <1265c2b4-565b-4f6f-ab73-bac58ddbfde4n at googlegroups.com>,
John Reagan  <xyzzy1959 at gmail.com> 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: 
>> >[big snip]
>> >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.

That makes sense; thanks!

	- Dan C.