jac@petsd.UUCP (Jim Clausing) (09/16/89)
I got the source for flex and bison off of sumex recently and last night
decided to try porting them since they are both MPW C (by the way, if anyone
else has already ported them and would like to save me the trouble, I would
be greatly obliged, assuming that that is not the case ...). I've run into
some slight difficulties and maybe a more major one.
Small problem #1: I get link errors with undefined bzero and mktemp. I know
that there is a PD C version of bzero floating around and I will try to find
that, what about mktemp?
Small problem #2: alloca. There are two assembler versions of this included,
but I don't have an assembler at present. Having never used the TC inline
assembler, how difficult would it be to take one of these assembly sources
and produce something that TC could handle? Should I not bother? Is there
a C version that (while perhaps slower) is useable.
Bigger problem (and petty gripe): (Before I even start, let me say that I
really like TC and I think the Symantec folks have done a great job, I've
been drooling all over the class library chapters of the manual, but haven't
had much time to play with it yet). The ever-present and truly obnoxious
data segment too big error (32K limit on data segment size). I don't want
to make wholesale changes to the code, is there an easy workaround for this?
What did MPW do, since this code apparently compiles there without problem?
On another (related to #2 note): Is it possible to link MPW .o files into
TC applications? There was a gnufuncts.o included somewhere, which would
probably take care of at least #2 and maybe #1. I will admit that I did not
RTFM here, my first thought was oConv, but it didn't recognize the .o file.
Since I am doing this for my own use and my employer is keeping me pretty
busy these days, I don't have the luxury of spending a lot of my own time
figuring this out just now. Any help would be greatly appreciated. E-mail
to me and I will summarize to the net. Thanx in advance.
---------------
Standard disclaimer: I don't claim the opinions of Concurrent Computer
Corporation (on the rare instances when CCC has them), so why should
they claim mine?
---------------
--
Jim Clausing Voice: (201)758-7693
Concurrent Computer Corp. Internet: jac@petsd.ccur.com
Tinton Falls, NJ 07724 UUCP: {att, rutgers, princeton}!petsd!jacearleh@eleazar.dartmouth.edu (Earle R. Horton) (09/16/89)
In article <1687@petsd.UUCP> jac@petsd.UUCP (Jim Clausing) writes: >I got the source for flex and bison off of sumex recently and last night >decided to try porting them since they are both MPW C (by the way, if anyone >else has already ported them and would like to save me the trouble, I would >be greatly obliged, assuming that that is not the case ...). I've run into >some slight difficulties and maybe a more major one. > >Small problem #1: I get link errors with undefined bzero and mktemp. I know >that there is a PD C version of bzero floating around and I will try to find >that, what about mktemp? The latest version of Flex on Sumex used Aztec C. It has not been ported to MPW C yet. Bzero() is trivial to implement. bzero(array, size) char *array; long size; { register long i; for (i = size; i-- > 0;) { array[i] = 0; } } Check the size parameter to see if you want a long or an int there. Mktemp() generates a unique file name from a template. The Aztec library contains one. For a single-user system, you can usually assume that the template passed to mktemp() is sufficiently obscure that it will not conflict with any permanent files, e.g. "/tmp/flexXXXXXX" and you can write a function that just returns the address passed to it. > >Small problem #2: alloca. There are two assembler versions of this included, >but I don't have an assembler at present. Having never used the TC inline >assembler, how difficult would it be to take one of these assembly sources >and produce something that TC could handle? Should I not bother? Is there >a C version that (while perhaps slower) is useable. Alloca() is dangerous. You need to know whether your compiler stores temporaries on the stack, and if so how many of them. The alloca() supplied with these programs copies the largest anticipated register save area before dropping the stack pointer, so that when the parent function returns it can restore its caller's registers. If you are using MC68881 code, the size of the save area needed will be much larger than provided for. If this is starting to sound a bit obscure, then you might need the C version. Assuming you have figured out the size of the largest possible temporary save area on the stack as used by TC, I should think porting the assembler code to TC inline "asm" should be real easy. > >Bigger problem (and petty gripe): (Before I even start, let me say that I >really like TC and I think the Symantec folks have done a great job, I've >been drooling all over the class library chapters of the manual, but haven't >had much time to play with it yet). The ever-present and truly obnoxious >data segment too big error (32K limit on data segment size). I don't want >to make wholesale changes to the code, is there an easy workaround for this? >What did MPW do, since this code apparently compiles there without problem? This is real easy. I compiled it with the large data option. Not so easy for you, eh? Earle R. Horton