Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!wuarchive!mit-eddie!uw-beaver!fluke!dyndata!dan
From: dan@dyndata.UUCP (Dan Everhart)
Newsgroups: comp.lang.c++
Subject: Re: calling Zortech C++ methods from assembly
Message-ID: <697@dyndata.UUCP>
Date: 25 Aug 90 17:14:18 GMT
References: <1990Aug17.142520.5402@aucs.uucp> <1394@proto.COM>
Organization: Dynamic Data & Electronics, Edmonds WA
Lines: 51
In-reply-to: joe@proto.COM's message of 18 Aug 90 04:57:46 GMT

In article <1394@proto.COM> joe@proto.COM (Joe Huffman) writes:

>  In article <1990Aug17.142520.5402@aucs.uucp>, 880716a@aucs.uucp 
>  (Dave Astels) writes:
>  > 
>  > I looked through the assembly sections of the compiler manual (2.06)
>  > but couldn't find the required info.  It only discussed calling assembly
>  > from C++ (with C linkage).  What I need is the information required to
>  > invoke C++ methods from assembly.

I agree.  If you're going to provide the spec for C <--> assembly, you
ought to provide the C++ spec as well.  We're encouraging people to
switch to C++, right?

>  The reason it isn't documented is because it can be a real
>  nightmare.

As professionals, we're used to dealing with nightmarish situations.
Or do you mean that it is a nightmare for Zortech to *document*?

>  The
>  names are mangled for type safe linking, there are hidden parameters 
>  ('this') and virtual functions are really function pointers (that may change 
>  their location between compiler versions).

Such variations can be described in a README.  In fact, why not
provide the information ONLY in the readme to prevent making the
manual obsolete when the protocol changes.

>  Basically, don't do it.  

Sorry, sometimes such things HAVE to be done in the real world.
Withholding the information just on principle is not helpful.

>  If you REALLY want to do it, call the function
>  from a C++ function, compile with -gl (line numbers turned on), then 
>  run OBJTOASM on the resultant .OBJ file.  [...]

Good advice, thanks.  Nevertheless, this technique will only tell you what
to do, leaving you to figure out for yourself why it is done that way.
(E.g. "Hmmm, what are all these constant additions and dereferences
doing?")

Myself, I needed to call a virtual member function from assembly.  To
get the program running quicker, I avoided reverse-engineering the
virtual function call sequence by calling a private regular member
function which calls the virtual function.  When the program is done
and needs to be optimized I will want to eliminate this extra call.
I'd like to see Zortech document the assembly -> C++ call, since it
would save me the work of figuing it out for myself.  There's the
nightmare :-)