Re: Moving VAX into 21 century :-)

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Aug 27, 2019, at 2:07 PM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> 
> On Mon, Aug 26, 2019 at 09:56:51AM -0400, Paul Koning wrote:
>> 
>> 
>>> On Aug 26, 2019, at 8:08 AM, Anders Magnusson <ragge%ludd.ltu.se@localhost> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have been looking at some VAX problems lately, and have found out that there are two architectural things things that probably would help VAX quite much.
>>> 
>>> 1) Change calling convention.
>>>    As described in my previous mail, it would solve a very old well-known performance problem.
>> 
>> You could of course change the code generator in GCC to do that.  It would be an ABI change, with far reaching impact.  Stack trace (GDB and elsewhere) would be completely different.  Function prologues would have to do register saving (not too difficult).  Exception handling would need to be redesigned.
> 
> Doesn't GCC already support this?  I have a fairly strong recollection of a -m switch for this existing in
> GCC in the early 1990s.

GCC has supported exception handling for ages, after all C++ needs it.  But it depends on work in the back end to teach it how to do that.  VAX, with the standard ABI, makes this very easy, but it still needs back end code to convey that to the GCC core.

There's also GDB backtrace.  I assume that works, it's hard to conceive of doing work with GDB without that.  Again, given the ABI it's just a matter of following FP.  If you want to create an alternate ABI for VAX that doesn't use CALL, it could still use a frame pointer if desired.  But probably that isn't desired (except where you must, perhaps because alloca() was used).  If so, GDB would have to be taught some other way of finding frame sizes to do backtrace.  That could be from debug info, or it could be by disassembling the code that constructs the stack frame.

	paul