gargulak@mozart.convex.com (Tom Gargulak) (11/02/90)
In article <MEISSNER.90Oct22135944@osf.osf.org>, meissner@osf.org (Michael Meissner) writes: > With the MIPS standard calling sequence (also used in DECstations, and > Silicon Graphics systems), there is one case that is impossible with > varargs, but can be handled with stdarg. If the first argument is > floating point, the MIPS calling sequence passes the number in a > floating point register, otherwise it passes the first argument in > integer registers. If the second argument was floating point and the > first one was as well, it too is passed in a floating point register, > otherwise it is passed in an integer register. The varargs stuff only > works for arguments passed in integer registers. Because varargs > functions don't tell the compiler anything in terms of a prototype, > the compiler doesn't have a clue that it should really pass the > floating point arguments in an integer register. So what does an MIPS ANSI-C compiler do in the case when the first two args are doubles? Does it store the floating point registers on the stack? I have not used an ANSI-C MIPS compiler. BTW: I know this is getting off the subject, but... I was amazed to find out that the MIPS compiler has different codegen when it sees "va_alist" in the parameter list in order to implement varargs. For example, the following two functions will have different codegen. test(Xa_alist) {} test(va_alist) {} No include files required. -Tom
gwyn@smoke.brl.mil (Doug Gwyn) (11/03/90)
In article <108077@convex.convex.com> gargulak@mozart.convex.com (Tom Gargulak) writes: >For example, the following two functions will have different codegen. > test(Xa_alist) {} > test(va_alist) {} >No include files required. Well, that's clearly wrong behavior, since both these are merely functions having a single int-valued parameter.
rfg@NCD.COM (Ron Guilmette) (11/04/90)
In article <14322@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <108077@convex.convex.com> gargulak@mozart.convex.com (Tom Gargulak) writes: >>For example, the following two functions will have different codegen. >> test(Xa_alist) {} >> test(va_alist) {} >>No include files required. > >Well, that's clearly wrong behavior, since both these are merely functions >having a single int-valued parameter. I think that it's wrong to say that that's wrong behavior. What's wrong with it? Are you assuming that the generated code not only is different, but also that the differences are detectable (other than simply speed differences)? He didn't say that the *different* code voilated any ANSI requirement for run-time behavior. If a va_list falls in the forest, and there is nobody there to hear it, does this violate ANSI rules? :-) I happen to be attuned to this issue because I've been implementing support for AT&T's new debug format (DWARF) in GCC. In order to generate *proper* debugging information, I have to check each function to see if its first parameter has a particular *special* name (which will indicate that it is an old-style varargs function). Now, does the fact that I generate different debugging information for functions whose first parameter is named `foobar' make the compiler that I'm working on non-standard? I doubt it. Would that fact that a given compiler generated different executable code for functions whose first parameter was named `foobar' in and of itself make that compiler non-standard. I don't think so. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
barmar@think.com (Barry Margolin) (11/04/90)
In article <14322@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <108077@convex.convex.com> gargulak@mozart.convex.com (Tom Gargulak) writes: >>For example, the following two functions will have different codegen. >> test(Xa_alist) {} >> test(va_alist) {} >>No include files required. >Well, that's clearly wrong behavior, since both these are merely functions >having a single int-valued parameter. If the code generated by each version has the same high level results, why is it wrong? Perhaps there might be miniscule performance differences, but does the any C specification say anything about relative performance of code generated from different pieces of source? I'd say that the behavior of this compiler is surprising, perhaps even undesirable, but I think it would be allowed by most language specs. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwyn@smoke.brl.mil (Doug Gwyn) (11/04/90)
In article <1990Nov3.235539.24204@Think.COM> barmar@think.com (Barry Margolin) writes: >If the code generated by each version has the same high level results, why >is it wrong? If the linkage is different, it's wrong. I thought that was what the original note suggested.
gargulak@mozart.convex.com (Tom Gargulak) (11/05/90)
In article <14322@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > >For example, the following two functions will have different codegen. > > test(Xa_alist) {} > > test(va_alist) {} > >No include files required. > > Well, that's clearly wrong behavior, since both these are merely functions > having a single int-valued parameter. Just because the codegen is different doesn't mean the behavior is. In this case mentioned here, the behavior for both is the same. Tom