On Tue, 2012-05-22 19:28:04 -0400, Dave McGuire
<mcguire%neurotica.com@localhost> wrote:
> On 05/22/2012 02:50 PM, David Brownlee wrote:
[libffi missing VAX support]
> > Various software packages including glib2 default to depending on
> > libffi. Obviously the dependency can be disabled, omitting that
> > functionality, but in case someone fancied a bit of VAX hacking I
> > thought I'd mention it on this list :)
>
> I think this is a great idea, but I don't think I can work on it. I
> have a few balls in the air at the moment.
Did you, by any chance, have had time to work on it?
I'm currently trying to set-up an automated toolchain builder with a
current version of NetBSD. It has a dependency on libffi (eg.
git->glib->libffi at least), so I've just started building some more
unrelated dependencies and will have a look at libffi.
After all, VAX calling conventions are quite simple. Just push
all 8, 16 and 32bit values onto the stack, the same for void pointer
and 64bit integers. (These seem to be mostly movq'ed, though), then
calls the respective function address, along with the number of
longwords (!) just pushed onto the stack (to unwind the stack
automatically on ret.)
So in comparison to a lot of other architectures/platforms/calling
conventions, where parameter distribution may be quite complex (eg.
some in registers, others on stack, complex patterns of registers
saved/restored during function call etc), VAX really is quite simple.
The only exception is call-by-value with structs. Here, new stack
space is allocated, copy the original struct (rounded up to full
longwords), and calls with an appropriate number of longwords to be
popped off the stack at return.
MfG, JBG
--
Jan-Benedict Glaw jbglaw%lug-owl.de@localhost
+49-172-7608481
Signature of: Eine Freie Meinung in einem Freien Kopf
the second : für einen Freien Staat voll Freier Bürger.
Attachment:
signature.asc
Description: Digital signature