davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/14/90)
Has anyone written an alloca for V.4? In spite of all the work done
for compatibility, there doesn't seem to be any library which has one.
Don't tell me to RTFM, it's miles away and I'm here trying to port a
program. I have alloca for Xenix, but not for V.4.
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -mevrs@lint.hf.intel.com.ogi.edu (10/18/90)
In article <2064@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Has anyone written an alloca for V.4? In spite of all the work done >for compatibility, there doesn't seem to be any library which has one. >Don't tell me to RTFM, it's miles away and I'm here trying to port a >program. I have alloca for Xenix, but not for V.4. I suspect (not know, but suspect) not. The compiler in V.4 is so optimizing that the output code doesn't resemble the input source all that much. In particular, the compiler plays fast and loose with stack frames, especially when inlining. This isn't really a V.4 issue, since a sufficiently optimizing compiler could/would have done the same thing on V.3. It just happens that the compiler on V.3 was not so smart, and alloca was still possible. Since it was possible, it was in fact done, and there was an alloca in the library, for those occasional programs that wanted it. If you want to, you can install your V.3 compiler and use that to bring up your application. Unfortunately, the promise was binary compatibility. Source compatibility was sacrificed where there appeared to be compelling reasons to do so. On the upside, a lot of source compatibility features were *added*. You'll like that the next time you are porting source from a BSD based environment. Stay away expecially from undocumented features (like alloca). >"Stupidity, like virtue, is its own reward" -me That is for sure. Vince
rcd@ico.isc.com (Dick Dunn) (10/19/90)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) had posted a while back asking for alloca() on V.4. I answered via email, but the topic's back again so maybe it needs a posting... vrs@lint.hf.intel.com.ogi.edu writes: > [Davidsen] > > Has anyone written an alloca for V.4? In spite of all the work done > >for compatibility, there doesn't seem to be any library which has one. ... > I suspect (not know, but suspect) not... alloca() is there; it's just not obvious. >...The compiler in V.4 is so optimizing > that the output code doesn't resemble the input source all that much... In a practical sense, the V.4 compiler seems to be about the same level of optimization as the V.3.2 compiler (and gee, I'd really rather the output code didn't resemble the input source that much, anyway...that's what I'm paying the compiler for:-) except for one area... >...In > particular, the compiler plays fast and loose with stack frames, especially > when inlining... It doesn't play "fast and loose." It simply doesn't maintain the frame pointer (%ebp) unless it needs to. This is a big win for programs with lots of small, frequently-invoked functions. > ...It just happens that > the compiler on V.3 was not so smart, and alloca was still possible... The compiler on V.4 is smart enough (unless you've got one from a fairly early drop), and alloca() is possible. The compiler generates proper frame-pointer handling code in functions which reference alloca(); it's a special case in the compiler. It's about the same as what gcc does on the 386. alloca() can be found in /usr/ucblib/libucb.a. This isn't a perfect solution; just adding the library to the compilation may alter other bits of reality. But you could extract alloca.o from the library to dodge that. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Never offend with style when you can offend with substance.
james@bigtex.cactus.org (James Van Artsdalen) (10/22/90)
In <1457@gandalf.littlei.UUCP>, vrs@lint.hf.intel.com (Vincent R. Slyngstad) wrote: | Has anyone written an alloca for V.4? > The compiler in V.4 is so optimizing that the output code doesn't > resemble the input source all that much. In particular, the compiler > plays fast and loose with stack frames, especially when inlining. > This isn't really a V.4 issue, since a sufficiently optimizing > compiler could/would have done the same thing on V.3. I don't think the v.4 compiler does that much better than the v.3 compiler. I'm not sure it's any better. It tries real hard to be ANSI, but doesn't seem quite there yet. The preprocessor makes a hash of its input (tokenizes everything, macros or not). The include files make curious assumptions about __STDC__. It is *not* necessarily the case that an optimizing compiler will fail to maintain stack frames. Stack frames are not expensive unless you make them that way, and in any case, function inlining can take care of truly trivial functions. I happen to like being able to debug programs - trading away debug capability for speed is a bad idea. gcc does a better job than the v.3 or v.4 compilers, yet it maintains stack frames. gcc can also be used on "old-style" sources, whereas the v.4 compiler cannot (yet - I assume this will change). > On the upside, a lot of source compatibility features were *added*. > You'll like that the next time you are porting source from a BSD based > environment. Stay away expecially from undocumented features (like > alloca). alloca(3c) is well documented and widely used. The "portable" alternatives are very poor. It would seem a major compatibility hole, so much so that it ought to be fixed. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/23/90)
On 18 Oct 90 03:04:13 GMT, vrs@lint.hf.intel.com.ogi.edu said: vrs> I suspect (not know, but suspect) not. The compiler in V.4 is so vrs> optimizing that the output code doesn't resemble the input source vrs> all that much. In particular, the compiler plays fast and loose vrs> with stack frames, especially when inlining. This isn't really a vrs> V.4 issue, since a sufficiently optimizing compiler could/would vrs> have done the same thing on V.3. Actually the optimizer of the stock compiler for V.3.2 does automatic inlining of small procedures by default, and if you want to use alloca() reliably you must turn off inlining with '-W2,-y0' if you specify '-O'. vrs> It just happens that the compiler on V.3 was not so smart, and vrs> alloca was still possible. alloca() is in SVR4, but in a place that is as improbable as -lPW in V.3.2; I seem to remember somebody saying it is in -lucb. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/23/90)
In article <48846@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: | alloca(3c) is well documented and widely used. The "portable" | alternatives are very poor. It would seem a major compatibility hole, | so much so that it ought to be fixed. It *is* fixed, I found it in the BSD library after finally looking enough places. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
tneff@bfmny0.BFM.COM (Tom Neff) (10/23/90)
If worst comes to worst you can always do
find / -name '*.a' -print | xargs nm -ehr | fgrep extern > allsyms.txt
which will pick up every damn library in the joint. :-)
--
Stalinism begins at home. }{ Tom Neff }{ tneff@bfmny0.BFM.COMtneff@bfmny0.BFM.COM (Tom Neff) (10/23/90)
In article <PCG.90Oct22214423@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >alloca() is in SVR4, but in a place that is as improbable as -lPW in >V.3.2; I seem to remember somebody saying it is in -lucb. I really recommend that people who are looking for things like alloca() take the time to run something like nm -ehr /lib/*.a /usr/lib/*.a | fgrep extern > allsyms.txt when they install or move to a new system. It saves so much time. -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.BFM.COM
rcd@ico.isc.com (Dick Dunn) (10/24/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >alloca() is in SVR4, but in a place that is as improbable as -lPW in > >V.3.2; I seem to remember somebody saying it is in -lucb. > I really recommend that people who are looking for things like alloca() > take the time to run something like > > nm -ehr /lib/*.a /usr/lib/*.a | fgrep extern > allsyms.txt Tom's advice is good, but unfortunately in some parts of the universe, the obsession with reorganizing, splitting out, rearranging, and generally changing-for-the-sake-of-change outstrips a moderately clever person's ability to figure out what's happened. In the case of V.4, alloca() is in /usr/ucblib/libucb.a (how many times have I posted that now?:-), so Tom's little searchit won't find it. And BTW, I don't claim to have found it by being more-than-moderately clever. I stepped in it after trying to decode the difference between /bin/cc (which is really /usr/bin/cc) and /usr/ucb/cc (which turns out to be a delightful 55-line shell script containing exactly one line of command, unless you also count the shell selection line #!/sbin/sh, but you probably shouldn't since it doesn't occur until line 8, and therefore probably doesn't do anything anyway, but I digress, and also run short of commas...:-) -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Never offend with style when you can offend with substance.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/24/90)
In article <1990Oct23.190425.5052@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: | Tom's advice is good, but unfortunately in some parts of the universe, the | obsession with reorganizing, splitting out, rearranging, and generally | changing-for-the-sake-of-change outstrips a moderately clever person's | ability to figure out what's happened. In the case of V.4, alloca() is in | /usr/ucblib/libucb.a (how many times have I posted that now?:-), so Tom's | little searchit won't find it. Yes, thanks. I originally asked if anyone had written one, and several people told me where to find it. Unfortunately I managed to blow away the disk doing something else, so until I borrow a tape drive again I am still out of luck. Has anyone made V.4 work with the EV-811 controller? If so, what's the secret? I have two, and neither will work, although they came via Bell Tech, who may have modified them more than they admit. Until I get either the secret to running the one I have, or one that works, or a controller, I am reduced to borrowing a tape drive every few weeks. When I get it reloaded I know where to find alloca, anyway. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
stevea@i88.isc.com (Steve Alexander) (10/26/90)
In article <15993@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >If worst comes to worst you can always do > find / -name '*.a' -print | xargs nm -ehr | fgrep extern > allsyms.txt >which will pick up every damn library in the joint. :-) Except, of course, for dynamic shared libraries, whose names end in .so or .so.<version>. Ah well. Besides, the UCB stuff is an optional package, and may not be installed on all systems. Now, if they'd just extend find to work on unmounted media :-) -- Steve Alexander, Software Technologies Group | stevea@i88.isc.com INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/29/90)
In article <15990@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: | I really recommend that people who are looking for things like alloca() | take the time to run something like | | nm -ehr /lib/*.a /usr/lib/*.a | fgrep extern > allsyms.txt | | when they install or move to a new system. It saves so much time. Yes, then you can post the request for alloca() just as I did. It turns out to be in /usr/ucblib, not my choice for standard location of the year. You get somewhere by doing this for all the libraries in /lib and /usr, but I think you still miss the stuff in some of the shared ones. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me