[Info-vax] How much of VMS is still in MACRO-32?

[Stephen Hoffman]

On 2021-06-03 00:48:33 +0000, Arne Vajhj said:

> On 6/2/2021 5:02 PM, Craig A. Berry wrote:
>> On 6/2/21 8:08 AM, Arne Vajhøj wrote:
>>> On 6/1/2021 9:34 PM, Craig A. Berry wrote:
>>>> On 6/1/21 12:33 PM, Stephen Hoffman wrote:
>>>>> On 2021-06-01 15:27:34 +0000, Marc Van Dyck said:
>>>>>> Don't you do that with Source Code Analyzer, for languages that support it ?
>>>> 
>>>>> I use DECset SCA and PCA only  rarely, as few sites have licenses for 
>>>>> that. Which means using symbol tables and maps, and the debugger,and  
>>>>> preferably refactoring where permitted.
>>>> 
>>>> And as far as I remember PCA doesn't work on shareable images, which 
>>>> means on any kind of application with a semi-modern architecture, you 
>>>> either do without

Last I looked, DECset PCA does have support for shareable images, but 
it has long reminded me of the debugger in that regard; of having to 
treat the image pieces ~separately, and not as parts of the same app.

The debugger was long one of the still-remarkable pieces of the OpenVMS 
development platform, but other platforms have reached parity with or 
have surpassed the debugger in recent years.

macOS with Xcode and Instruments utterly blows away the DECset 
performance-related and memory-related tooling, for instance.

>>> Would it ignore the time spent in the shareable image or would it just 
>>> count it as being spent in the calling code?
>> 
>> IIRC, it counts it all as being in the calling code.
> 
> That makes sense.

It made sense in the last millennium on a VAX and with ~30 bits of 
address space for apps and tooling. Now? Not so much.

Now? Treating shareable images separately is just dumb. Can you 
symbolicate each piece? Show it. No symbols? Display what you can. And 
get better at reversing executable images when symbols are unavailable. 
q.v. Ghidra, for reversing.

>>> The latter may be good enough for many purposes.
>> 
>> Not when you have a tiny bootstrap program that loads a library to do 
>> all the heavy lifting -- then it tells you that 99.9999% of the time 
>> was taken by the one routine that loads the library. I believe this is 
>> a fairly common architecture; it's certainly one way to make a package 
>> that can be run standalone but also be embedded in other programs.
> 
> If you need you application to be both standalone and embeddable then 
> that is what you have to do.
> 
> I don't know how common it it.

Having an app that can build both as standalone monolithic and as 
shareable images is vanishingly rare. One of the very few apps around 
that (sort of) does do this is SQLite.

Breaking up apps into callable hunks and into UI or networking or web 
other app-specific pieces is ubiquitous, of course. Those hunks get one 
or more object libraries, and the shareable images for deployment. Get 
the shareable image hunks working separately, build test harnesses for 
each hunk, and re-use the hunks across various executables, and update 
the hunks as needed. These hunks of code can be created for various 
purposes; to ease and isolate and modularize app development, for 
porting to some new UI, or for porting code to another platform 
entirely.

OpenVMS developer tooling needs help. What the Visual Studio Code IDE 
provides is a start. More work is needed for the tooling, and for VSC.  
It'd be interesting to see the changes and the rate of change, were VSI 
to integrate with and encourage the use of VSC internally, too.  
Downside of development tooling, of course: developers can have decades 
of investments in a specific set of tooling, and changing tooling (from 
edit-compile-link-debug-command-line, or from some other IDE) is no 
small investment of time and focus and effort.  Ah well. But I digress. 
"Time to re-launch Xcode for this coding project", Hoff said swiftly.





-- 
Pure Personal Opinion | HoffmanLabs LLC