janin@tybalt.caltech.edu (Adam L. Janin) (10/08/88)
I just installed Bison on a Mac II and I'm having a problem when linking. Using bison.simple, I get a link error (missing functions alloca and bcopy). When I use bison.hairy (using the %semantic_parser command), I get other link errors (several missing functions). I assume I should simply replace alloca with NewPtr and bcopy with MemCopy. Is this correct? Also, under what conditions would I want to use bison.hairy as apposed to bison.simple? Thanks, Adam Janin janin@tybalt.caltech.edu or janin@csvax.caltech.edu
swilson%thetone@Sun.COM (Scott Wilson) (10/09/88)
>I just installed Bison on a Mac II and I'm having a problem when linking. >Using bison.simple, I get a link error (missing functions alloca and bcopy). >When I use bison.hairy (using the %semantic_parser command), I get other link >errors (several missing functions). I assume I should simply replace >alloca with NewPtr and bcopy with MemCopy. Is this correct? Also, under >what conditions would I want to use bison.hairy as apposed to bison.simple? NewPtr will not give you the equivalent of alloca. What you should do is look at the functionality of alloca and bcopy and either add your own routines or replace them with an equivalent. For your reference their definitions are (from SunOS 4.0): char *alloca(size) int size; alloca() allocates size bytes of space in the stack frame of the caller, and returns a pointer to the allocated block. This temporary space is automatically freed when the caller returns. and: bcopy(b1, b2, length) char *b1, *b2; int length; bcopy() copies length bytes from string b1 to the string b2. Overlapping strings are handled correctly. Notice that the argument order of bcopy is reversed of the SysV similar routine called memcpy. As for alloca, you can write your own in assembler or you can try the "portable" alloca in C form that comes with GNU emacs. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (10/09/88)
In article <8246@cit-vax.Caltech.Edu> janin@tybalt.caltech.edu (Adam L. Janin) writes: >I just installed Bison on a Mac II and I'm having a problem when linking. >Using bison.simple, I get a link error (missing functions alloca and bcopy). >When I use bison.hairy (using the %semantic_parser command), I get other link >errors (several missing functions). I assume I should simply replace >alloca with NewPtr and bcopy with MemCopy. Is this correct? > Thanks, > Adam Janin > janin@tybalt.caltech.edu or janin@csvax.caltech.edu Oh, no, it's the "alloca" argument all over again. I believe that alloca is a function to allocate local storage. The difference between it and malloc is that all storage allocated by alloca will get disposed _automatically_ whenever the function that called alloca returns. The problem comes in on the "automatically" part. I believe that in general implementing "alloca" can be quite difficult on some architectures, and often needs some pretty close consideration on the part of the compiler. Some people have argued that just having the ability to do an "alloca" implemented can seriously slow down function calls, especially on some RISC machines. Thus, some people have argued that "alloca" should be abolished from use, replaced, by explicit allocate/free calls. Unfortunately, Richard Stallman is pretty dogmatically in favor of the other side, and so it looks like "alloca" will continue to be used in many FSF programs (of which Bison and Emacs are examples). The bottom line for your specific problem is: You might either have to write "alloca" (Which might be quite difficult). Or, you have to modify Bison to use malloc and the appropriate free call explicitly. In this respect, the UNIX call "malloc" is analogous to the MacOS call "NewPtr." If you replace all calls to "alloca" to "malloc" or "NewPtr", it will still work, but you will get serious memory fragmentation over time. I think that "bcopy" does just about the same thing as "BlockMove". Matt Kennel mbkennel@phoenix.princeton.edu
swilson%thetone@Sun.COM (Scott Wilson) (10/09/88)
>Unfortunately, Richard Stallman >is pretty dogmatically in favor of ... Richard Stallman dogmatic? Shirely, you jest! From the GNU Emacs manual: I strongly recommend that you try out the indentation style produced by the standard settings of these variables, together with putting open braces on separate lines. You can see how it looks in all the C source files of GNU Emacs. Geez, the man wants to tell me how to indent my code! BTW, I looked at the source, and I don't think a two character indent is sufficient; the code, in my opinion, was hard to read. The point, though, is that it's a matter of personal taste. I had a rather lengthy mail discussion with Mr. Stallman regarding the use of constructs of dubious portability in GNU code. My argument was that if the FSF really wanted to do computer users a favor by giving away free code then they should produce code that is more likely to succeed in compiling and running on a greater number of machines. His reply was that GNU (the OS) will support all the features that current GNU code exploits. His ultimate goal is a complete system and he would rather spend time on making that a reality than worrying about how portable bison is to the Mac. He does have a point, but somehow I get the feeling that FSF produces software that works only in environments deemed worthy by the authors. My impression is that spreading their computing philosophy is more important than giving users a choice. But, alas, I have to give them credit. Their useful software produced to money charged ratio is infinitely larger than mine. Please direct all flames by e-mail to me where they will be promtly deleted, I'm sure this newsgroup cares not too much. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
earleh@eleazar.dartmouth.edu (Earle R. Horton) (10/10/88)
In article <8246@cit-vax.Caltech.Edu> janin@tybalt.caltech.edu (Adam L. Janin) writes: >I just installed Bison on a Mac II and I'm having a problem when linking. >Using bison.simple, I get a link error (missing functions alloca and bcopy). >When I use bison.hairy (using the %semantic_parser command), I get other link >errors (several missing functions). I assume I should simply replace >alloca with NewPtr and bcopy with MemCopy. Is this correct? Also, under >what conditions would I want to use bison.hairy as apposed to bison.simple? Alloca() is a non-portable function that allocates storage in the local stack frame of the caller. Said storage vanishes when the caller of alloca() returns. The stack frame convention used in MPW high level languages makes implementation of alloca() trivial, as shown below. Bcopy() is similar to BlockMove() and to memcpy(). Memcpy() is more portable to use because I think it is in ANSI C(?). I compiled the original GNU sources for Bison from prep.ai.mit.edu on my Mac II with little difficulty. However, I have yet to use the "%semantic_parser" command or to figure out what it is for, although I did notice that it generates link errors. I also got the posted sources by Pierce T. Wetter, and compiled them. I notice that bison.hairy does not work there either. My feeling is that Pierce did not get it working, but you might ask him, since his mail address is also at Tybalt.Caltech.Edu. This is the assembler source to alloca() for use with Macintosh Programmer's Workshop C. Notice that it must be assembled with MPW assembler. If you do not have the assembler, then I can whip up a C version using InLines if you like. ;; ;; Alloca() for Macintosh Programmer's Workshop C. ;; alloca(n) allocates n bytes of storage in the stack ;; frame of the caller. ;; CASE ON alloca PROC EXPORT move.l (sp)+,a0 ; pop return address move.l (sp)+,d0 ; pop parameter = size in bytes add.l #3,d0 ; round size up to long word and.l #-4,d0 ; mask out lower two bits of size sub.l d0,sp ; allocate by moving stack pointer move.l sp,d0 ; return pointer add.l #-4,sp ; new top of stack jmp (a0) ; return to caller ENDP END Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Sorry, no fancy stuff, since this program limits my .signature to three
orjan@nada.kth.se (Orjan Ekeberg) (10/11/88)
In article <10329@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: (Text removed) >alloca PROC EXPORT > move.l (sp)+,a0 ; pop return address > move.l (sp)+,d0 ; pop parameter = size in bytes > add.l #3,d0 ; round size up to long word > and.l #-4,d0 ; mask out lower two bits of size > sub.l d0,sp ; allocate by moving stack pointer > move.l sp,d0 ; return pointer > add.l #-4,sp ; new top of stack > jmp (a0) ; return to caller > ENDP > END I tried a similar version of alloca some year ago and seem to remember that it had problems with the C compiler optimizations. Instead of popping garbage from the stack after each call, it sometimes leaves it on the stack and increments the stackpointer later. Problems occur when alloca is called in the meantime. The beginning of the allocated area will then probably be overwritten by another stackframe. I have also tried the portable alloca provided with Gnu Emacs (I think) and it seems to work properly.