[Info-vax] September 6, 2016 - new Roadmap and State of the Port updates now on VSI website

[Stephen Hoffman]

On 2016-09-10 01:12:58 +0000, David Froble said:

> John Reagan wrote:
>> On Thursday, September 8, 2016 at 9:54:57 PM UTC-4, David Froble wrote:
>>> John Reagan wrote:
>>>> On Thursday, September 8, 2016 at 3:44:19 PM UTC-4, David Froble wrote:
>>>>> Ok, I'll throw out an idea here.  Not saying it's a good idea, and I'm 
>>>>> sure Steve won't like it.  Well, pretty sure.
>>>>> 
>>>>> How about two C compilers on VMS?  One for VMS users, and one aimed at 
>>>>> porting needs.
>>>>> 
>>>>> I'd assume that they would be almost identical,so common code could be 
>>>>> used in the compilers.  Don't know how difficult this would be.  Most 
>>>>> likely a John Reagan question.
>>>>> 
>>>>> Not saying leave either of them in the past.  Both should be kept 
>>>>> current, and mostly logical name free.  Just saying, if what's needed 
>>>>> for porting *ix snake oil just isn't compatable with more traditional 
>>>>> VMS users, then face up to the issue and address it in some workable 
>>>>> manner.
>>>> That's basically what you are getting.  The DEC C frontend hooked to LLVM
>>>> gets you the C99 compiler with all of the strangeness that you want (there
>>>> will probably be some things changing/disappearing - #pragma linkage for
>>>> example).  I don't see that compiler getting any C11, etc features.
>>>> 
>>>> And then you have clang (which is several compilers rolled into one).  That
>>>> compiler has all the standard's compliance you want but currently none of the
>>>> OpenVMS extensions you want.  That is what we'll be doing.  We'll try to
>>>> limit the changes to the smallest set possible.
>>>> 
>>>> Do you mix objects from both compilers?  Yes from the calling standard point
>>>> of view, but they often contain calls into the RTL. Do the compilers share
>>>> the same CRTL?  Can you malloc() in one and free() in the other?  Can you
>>>> fopen() in one, but fclose() in the other.  Are the "errno"s the same or not?
>>>> If you pick up C11 headers, etc. do you let them work in the DEC C case?  Or
>>>> is that just __STDC_NO_THREADS__ ?
>>> If there is a problem, then it is a stupid problem.  I can allocate 
>>> memory from Macro-32, and deallocate it from Basic.  Or the opposite.  
>>> Or substitute any of the VMS languages.  So what's the problem?  They 
>>> are still using VMS services to do the job, right?
>> 
>> As Steve said, there are abstractions above the calls to LIB$GET_VM and 
>> LIB$MALLOC.  You wouldn't expect to do a NEW in Pascal, pass the 
>> pointer to a C routine and do a free(), would you?  However, when it is 
>> the same language, you expect that to work regardless of the compiler 
>> used.  Do you want to mix DEC C objects and clang objects?  Given that 
>> we will only have clang++, it is a given that we'll have to let you mix 
>> DEC C objects with clang++ objects.  The line between C and C++ is 
>> fuzzy.  I think it is expected to malloc() in one and free() in the 
>> other.
>> 
>> On the other hand, you can't easily mix g++ and clang++ objects on a 
>> Linux box since there might be differences in vtables, etc.
> 
> Personal opinion.
> 
> I think that when you implement an environment on top of another 
> environment, then you're no longer really running executables under the 
> lower (not sure what term) environment.  In this case, if special stuff 
> is implemented in C, then by using it you're no longer running on VMS.
> 
> I also think that if you're going to claim that you're running 
> executables on VMS, then it should always be VMS services used to do 
> things, not some language specific replacement of a VMS service.
> 
> But what do I know ???


-- 
Pure Personal Opinion | HoffmanLabs LLC