[Info-vax] C troubles: BADSTATICCVT

[Stephen Hoffman]

On 2018-02-02 14:48:36 +0000, John Reagan said:

> If you come with me into the Tardis (don't worry, there's plenty of 
> room) and go back in time, you'll find lots of code shared between VAX 
> and the soon to be Alpha.  While the VMS group cloned the source pools, 
> there is lots of code shared there as well.  There is LOTS of Macro-32 
> code and LOTS of BLISS-32 code.  That code is full of 32-bit 
> descriptor, 32-bit itemlists, and shoving VAX code addresses into 
> 32-bit locations.  While well-written BLISS might be easily transformed 
> into BLISS-64 code, Macro-32's ability to abstract the size of things 
> is horrible.  All those "L" letters in things like MOVL, ADDL, etc.  
> making the compiler turn "L" into "LL" or MOVAx now makes a 64-bit 
> value leads down the road to madness.  Looking back, I think I want to 
> point a finger at itemlists (and to a lesser degree descriptors).  The 
> exposure of "address" into languages that don't have that concept ended 
> up with %LOC into INTEGER*4's in Fortran or even worse COBOL.  The 
> time, effort, risk, and pressure from customers to "recompile and go" 
> lead us into the dual pointer environment.  I do remember discussing a 
> hard split and doubling of libraries, etc. and mixed interaction 
> (passing Fortran LUN numbers around as an example) make that solution 
> complicated as well.  Nobody wanted to try to tackle RMS-64 (then or 
> now).  Just think about a cluster-wide shared indexed file being 
> read/updated from both RMS-32 and RMS-64 code stacks.  Toss in 
> process-perm-file handling...

Yeah, and all that technical debt then spread into and throughout the 
64-bit app source code.  When workarounds become visible and which is 
the inevitable outcome whenever compatibility is in ascendance, 
problems can't get fixed and apps can't get simpler.  For those of a 
certain age, this has certain parallels with the "fun" that was TKB.

I don't see sharing of access to indexed files as a particular issue, 
though.  Instantiate a new indexed file type that's 64-bit native, and 
require all apps to use 64-bit to access those files.   There's not a 
whole lot of reason for new 32-bit work, and there's no chance at all 
of updating the 32-bit APIs due to compatibility.   Which means 64-bit 
flat native is a break.  Which means APIs can get fixed.   And a break 
means adoption will be slower.  But then this work is is a 
more-than-a-quarter investment, too.

The only reasonable remaining option in this era is a wholesale 
migration to OO APIs.  There's not much point in spending effort 
draining the 32-/64-bit swamp now, nor of hauling more code using 
itemlists and descriptors forward, nor of "just" a flat 64-bit address 
space and tools.  Unfortunately, moving to OO is far larger effort than 
was 32-/64-bit or of the didn't-happen-yet fully-native 64-bit.

It's indicative of the more general problem VSI is facing, too.  
Hauling OpenVMS forward to competitiveness is a massive effort, and VSI 
(presently) isn't staffed nor funded for the scale of that.

Which means OpenVMS is where it is and for the foreseeable future, and 
with incremental work to resolve specific issues existing sites are 
encountering and not the least of which involves the x86-64 port.

Which is good for the installed base.  But isn't going to lure a whole 
lot of new folks over to OpenVMS.  Which means incremental growth of 
the existing installed base, and preferably whilst avoiding the accrual 
of yet more technical debt.  Which reminds me, I need to get a quote 
from y'all.


-- 
Pure Personal Opinion | HoffmanLabs LLC