From: Dave Weatherall [djw-nothere@nospam.nohow] Sent: Friday, January 09, 2004 2:56 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: Could OpenVMS-Athlon ever be? On Thu, 8 Jan 2004 20:28:44 UTC, John Reagan wrote: > I really don't know where to start on this one... > > - Porting Macro-32 to 8086 would be very difficult. The biggest issue > the lack of sufficient registers on 8086. Think of Macro32 source code > has having several 'predeclared variables' named R0, R1, etc. that are > global to all routines. On Alpha and Itanium, there are sufficent > hardware registers for all of that to work although the Calling Standard > on OpenVMS I64 makes it a little interesting. On 8086, I really have no > clue how to efficiently generate code for Macro32 routines that pass 8 > 'registers' between each other (or between Macro32 and BLISS or C > routines) for instance. Macro32's use of GEM is unique compared to the > other GEM-based compilers. We have our own code generation and just use > GEM for object file writing, peepholing, instruction scheduling, etc. > The fact that there exists a current 8086 GEM doesn't help Macro32 much. > For instance, for the port to Itanium, we had to gut the code > generation modules from the OpenVMS Alpha compiler and completely > reimplement them for Itanium at a cost of several person-years. > > - Not all of the compiler people are at Intel. I'm not. We still have > engineers to support GEM and our front-ends on all their current targets > as needed. Intel isn't porting any compilers to OpenVMS. We are taking > some compilers from Intel (C++ right now, C in the future, Fortran is > somewhat unique) and WE are porting/adapting them to OpenVMS. Also, > OpenVMS customers require more than just C, C++, Fortran, There are > COBOL, Pascal, and BASIC customers as well as BLISS customers > internally. I know that even the current 8086 GEM wouldn't be > sufficient for those compilers on traditional 8086 targets. More work > would be needed. > > - Even if Intel produced some sort of mythical 64-bit 8086, again, is > Intel going to give us a BLISS or any other OpenVMS compiler? I think > not. For our compilers that are GEM-based, Intel isn't going to do a > 64-bit 8086 GEM target. That would all be work we'd have to do. The response is appeciated John and the argument understood. The lack of registers has always been a reason why I was never keen on x86. I'm sure the argument was even more powerful 10 years ago. That said :- Any x86 MACRO-32 compiler would assume that it was targetting an x86 version of VMS. If this was done with a virtual machine or memory-based register stacks then the problem of mapping the VAX registers would/could have been resolved. I do remember reading in some book, way back when I was still playing with x86 machines, that the x86 architecture was not so IIRC 'reliant' on registers because it viewed all available memory as if it were a set of registers. I confess to not having been convinced - we were barely into 286/386 at the time. Since then, however, Intel, Cyrix and AMD have made this statement more of a reality (and quietly added more registers onto the silicon) How that would relate to GEM I'm not sure as I know nothing about it really. Did the NT BLISS compiler use GEM or was that a complete re-implemenation? Does VMS BLISS use GEM even? One area that would definitely be a problem is DEC Floating Point support but that has nowt to do with programming language. -- Cheers - Dave.