[Info-vax] C and assembly language, was: Re: WHY IS VSI REQUIRING A HYPERVISOR FOR X86 OPENVMS?

[John Reagan]

On Tuesday, December 22, 2020 at 1:17:28 PM UTC-5, Simon Clubley wrote:
> On 2020-12-22, John Reagan <xyzz... at gmail.com> wrote: 
> > On Tuesday, December 22, 2020 at 11:30:10 AM UTC-5, Simon Clubley wrote: 
> >> On 2020-12-21, Wilm Boerhout <wboerhou... at this-gmail.com> wrote: 
> >> > John Reagan schreef op 21-12-2020 om 02:55: 
> >> >> 
> >> >> "Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms. 
> >> >> 
> >> > 
> >> > Apropos DECnet IV: a bunch of us in the HECnet alternate universe have 
> >> > been running pydecnet (that is, DECnet IV written in python from the 
> >> > original DECnet specifications) for a while now, thanks to Paul Koning's 
> >> > implementation effort ***bows to Paul*** 
> >> > 
> >> $ set response/mode=good_natured 
> >> 
> >> DECnet Phase IV in Python ??? That's just unnatural. ;-) 
> >> 
> >> On a more serious note, I wonder why John was looking at the DECnet 
> >> Phase IV code. I wonder if something in there found a problem in the 
> >> new compilers ? 
> >> Simon. 
> >> 
> >> -- 
> >> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP 
> >> Walking destinations on a map are further away than they appear. 
> > No conspiracies here. We were looking at the code that did MAC address lookups for MOP loads. It has some Alpha vs Itanium conditionals. I was asked by another engineer to explain why the two platforms were different what x86 needs. The original VAX version pushed routine addresses on the stack and did some "JSB @(SP)+" along with some hard resets of the SP (think of it as a cheap form of setjmp/longjmp). You can't do a store into SP on Itanium so the code had to do something else. 
> > 
> > If you want a list of known bugs with the current x86 cross-compilers? I have that list too. There are several. I'm currently working on a linker issue that cropped up with our bootstrapping native compilers to x86. Our linker doesn't handle code in SHT_GROUP but EH data not in the group. It ended up trying to apply relocations to non-existent code. A sanity check was raised. What else do you want to know? For C, I have one bug dealing with a #pragma linkage, one with changing "align(page)", and request for a new builtin to read/write the Time Stamp Counter. There are a few open for Macro-32 and two for BLISS (all worked around with simple edits). 
> >
> No conspiracy theory here. :-) 
> 
> As I am sure _everyone_ around here knows, production code that was 
> working just fine in an old environment can sometimes break big time 
> in a new environment. Sometimes it turns out the code was only accidently 
> working :-) and sometimes it turns out the code found a problem in 
> the new environment. I was just curious if it was something like that.
> Simon. 
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP 
> Walking destinations on a map are further away than they appear.
Oh, you want one of THOSE stories?  Here's one.

Consider a broken C routine that is declared "int" but one or more paths don't have a valid 'return' statement.  On Alpha/Itanium, the value in R0/r8 is often the return value from a prior call to something.  GEM doesn't really want to reuse R0/r8 for any kind of temporary since it won't live past the next routine call (it will use them if pushed into a corner).  The return without a 'return' just gets you that prior R0/r8 value.  If your 'int' routine is really a true/false routine, you might have been working for years without any problems.

However, given the few registers on x86 (and how some of the instructions work), the return register %rax is used in many places for a short-term temporary.  So when the C routine exits without a 'return' statement, the value in %rax can be very strange.

The C program has been broken on every platform.  If you would have used something like /WARNING=ENABLE=QUESTCODE, the compiler can help identify those paths without a 'return'.  You can look for those broken programs today on Alpha or Itanium.  [I've been tempted to promote that check out of the QUESTCODE category and have it enabled by default.  That decision was done long ago before I was in a position to do anything to help.]