880716a@aucs.uucp (Dave Astels) (08/17/90)
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. Thanks in advance. -- "I liked him better before he died" - McCoy, ST V =============================================================================== Dave Astels | Internet: 880716a@AcadiaU.CA PO Box 835, Wolfville, | Bitnet: 880716a@Acadia
joe@proto.COM (Joe Huffman) (08/18/90)
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. The reason it isn't documented is because it can be a real nightmare. 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). Basically, don't do it. 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. This will generate the assembly code from the object code the compiler generated. This will show you the mangled function name, how it's done with the current version of the compiler and with that particular function. --- Zortech mailing list: send email to 'ztc-list-request@uunet.uu.net' with: Add: your-use-name@your-site In the body of the message. -- joe@proto.com uunet!proto!joe FAX: 208-263-8772
pwt@otter.hpl.hp.com (Peter Toft) (08/20/90)
C++ function pointers can be passed in to the assembly code, which can then subsequently be called from within the assembly routines. I've done this when calling C++ from C, usually by having a 'setup' routine in the C code that is called from C++ to set up the pointers to the required C++ functions. This gets around having to know the mangled names. =============================================================================== Peter Toft, ARPANET pwt@hplb.hpl.hp.com Hewlett-Packard Laboratories, JANET pwt@lb.hp.co.uk Filton Road, UUCP ...!mcvax!ukc!hplb!pwt Stoke Gifford, CSNET pwt%hplb.csnet@relay.cs.net Bristol. HPdesk Peter TOFT / HPC600 / 05 BS12 6QZ. Phone UK (0272) 799910 ext 24245 United Kingdom. Int'l +44 272 799910 ext 24245
880716a@aucs.uucp (Dave Astels) (08/20/90)
In article <1394@proto.COM> joe@proto.COM (Joe Huffman) writes: >In article <1990Aug17.142520.5402@aucs.uucp>, 880716a@aucs.uucp >(Dave Astels) writes: >>[...] invoke C++ methods from assembly. > >The reason it isn't documented is because it can be a real nightmare. Most really powerfull things are. >The names are mangled for type safe linking, No problem. I've read the sections on name mangling and it is simple enough. >there are hidden parameters ('this') Again no problem. Just an extra push or two. >and virtual functions are really function pointers (that may change >their location between compiler versions). This can be a problem. However, if I need to invoke a virtual method, I can have a non-virtual one to invoke which will take care of invoking the virtual one. >Basically, don't do it. 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. This will generate the assembly >code from the object code the compiler generated. This will show you >the mangled function name, how it's done with the current version of the >compiler and with that particular function. I had hoped not to have to resort to this again (this is how I taught myself the C calling convention. I've done this (asm->C++) successfully using Turbo Pascal 5.5, so the tricks (implicit parameter, etc) aren't new to me. Borland outlines ALL calling conventions fully in the TP5.5 manuals. I do wish Zortech would give full information in their manuals, for those of us who enjoy getting our hands dirty. -- "I liked him better before he died" - McCoy, ST V =============================================================================== Dave Astels | Internet: 880716a@AcadiaU.CA PO Box 835, Wolfville, | Bitnet: 880716a@Acadia
bright@Data-IO.COM (Walter Bright) (08/21/90)
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.
Probably the easiest way to figure this out is to write a function that
calls a method in C++, compile it with the -gl switch, and run OBJTOASM
on the output.
In general, arguments are pushed left-to-right, the 'this' pointer is
pushed last, and the callee cleans up the stack. To get the 'mangled'
name of the method to call, run OBJTOASM on the .OBJ file that contains the
definition of the method.dan@dyndata.UUCP (Dan Everhart) (08/26/90)
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 :-)
joe@proto.COM (Joe Huffman) (08/26/90)
In article <697@dyndata.UUCP>, dan@dyndata.UUCP (Dan Everhart) writes: > In article <1394@proto.COM> joe@proto.COM (Joe Huffman) writes: [...deleted stuff...] > 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? Encourage? Yes! Provide a 'spec' that may change version to version? I'm not so sure. A spec to me implies some sort of commitment to avoid change. Also the 'C++' interface it is not nearly as 'clean' an interface as the 'C' interface. It is more complex (some functions receive arguments pushed left to right others right to left) and changing the interface was an option that was preferrable to keep open. > > 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*? It would only take time. Time to do the documentation, time to bring the tech support people up to speed, and time spent on the phone with people that misread the documentation. If someone had asked me whether it should be documented I would have only needed to think about it for two or three seconds before decideing that it shouldn't be necessary. I can only think of one application where you MIGHT want to call C++ from assembly language (an interrupt service routine, where you need to do an 'iret' instead of an 'ret'). And then there are easy work-arounds. > 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. If we were to do it I think you have good advice here. READ.ME only documentation. Fewer people will try it, less support problems, a more casual 'tone' where you can advise them of the risks more forcefully, etc. > > 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. I'm sure the reason was to leave more options open, not "just on principle". And I'm not yet convinced that "such things HAVE to be done". I have written many tens of thousands of lines of "real world" code. You almost certain have even used some of my code. And I am unconvinced that it is really a necessity from a programming perspective. From a customer relations perspective, I am nearly convinced it's important (but not that we "HAVE" to). > Good advice, thanks. You're welcome. :-) > 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 :-) If you only have one or two functions you need to call, the reverse engineering approach using the method I discribed would probably be quicker and easier than reading several pages of documentation with all the special cases enumerated and trying to figure out which case your function fell into. I'm sure that this will be discussed internally at Zortech and a decision made about how to handle it... Would you email me a reason you "HAVE" to do this? If you really want this done you will have to convince some people that it's necessary... -- joe@proto.com uunet!proto!joe FAX: 208-263-8772