[Info-vax] Exceptions, Code Optimization (was: Re: New VSI Roadmap (yipee!))

[Stephen Hoffman]

On 2015-03-03 16:32:18 +0000, David Froble said:

> But yes, what you suggest would be a good thing.  Modular programming 
> techniques lead to calling subroutines and external functions, and 
> improving that would be helpful.
> 
> How do other languages handle such?

This particular BASIC case is as much about the error handling as the 
calls themselves.    Most (all?) of the VMS compilers can use 
lib$establish as a "language keyword" now rather than as a subroutine 
call from the OpenVMS VAX days, and the compilers also tend to push the 
overhead of the errors and the exceptions into the routines that are in 
the error paths.  This works around the differences from how VAX 
architecture worked, and this "language keyword" approach works pretty 
well for most applications, but the performance of those applications 
that used signals all over the place suffered.  With lib$establish, the 
newer compilers (mostly) implement the behavior that VAX presented, and 
thus that OpenVMS application programs using lib$establish expected.

As for how other languages and other platforms handle these cases, that 
varies.  Widely.  For iOS and OS X platforms with Objective C, those 
programs incur some overhead at each method invocation via the 
objc_msgSend path 
<http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/>. 
  How that gets used — the conceptual mechanism of message passing, and 
the protocols and overrides that then become available — generally 
looks strange to folks accustomed to procedural-style invocations in 
languages such as C, BASIC, Fortran or COBOL.  The flexibility from the 
method invocations and the message passing abstractions can be very 
useful, though.   The clarity, once you get the hang of it, too — the 
details of the various interfaces among the hunks of code are not wired 
together to nearly the same degree as arises with C, BASIC, Fortran and 
COBOL code, for instance.

For programming in general, what happens usually involves implementing 
the code with maintainability foremost in mind, and implementing with 
or reworking the algorithms or reworking the code or hand-optimizing 
some assembler code for performance where that's strictly necessary; in 
sections of the code where the constraints are the tightest and 
performance requirements the highest.  This  can end up trading 
increased executable code size for better performance, or increased 
maintenance effort for performance.   Much as having BASIC rummaging 
the call stack, using message passing and the associated objc_msgSend 
calls in a tight and performance-critical loop probably isn't the best 
idea, for instance.

BASIC works and works well for certain sorts of tasks and applications, 
but — as BASIC is implemented on VMS — BASIC can also be a whole lot of 
coding work, for what you get out of it.  Different programming 
languages have different sweet spots, of course.  Different compilers 
and different linkers and different image-optimizing tools — tools such 
as Caliper 
<http://www.eecs.harvard.edu/~fedorova/sim299/papers/hundt.pdf> and the 
inter-module optimization with OM 
<http://dl.acm.org/citation.cfm?doid=773473.178260>, come to mind here 
— can find different advantages, as well.  Much like acquiring an 
appreciation for how some of the existing source code got the way that 
it is — such as existing source code that originated within the 
limitations of the PDP-11 and RSX-11M/M+, and within the pit of fire 
known as TKB, for instance — have a look at how the kids are coding 
now, and what tools are in use, and what advantages can be had from 
these new approaches and new tools.  If any, of course.




-- 
Pure Personal Opinion | HoffmanLabs LLC