Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!proto!joe
From: joe@proto.COM (Joe Huffman)
Newsgroups: comp.lang.c++
Subject: Re: calling Zortech C++ methods from assembly
Summary: We'll think about it...
Message-ID: <1407@proto.COM>
Date: 26 Aug 90 05:37:40 GMT
References: <1990Aug17.142520.5402@aucs.uucp> <1394@proto.COM> <697@dyndata.UUCP>
Organization: Prototronics; Sandpoint, Idaho
Lines: 76

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