bli@castor.usc.edu (Binary Logics) (06/04/90)
I am trying to get DME v1.30 (or so the doc file says) to compile on my system, using Aztec 3.6a (still... :-) I can get it to compile fine, but at link time, it tells me that some functions that should be in Matt's Suplib (and ARE!) are undefined. They are _bzero, _bset, and _bmov. I even tried assembling those functions separatelly and making a new lib of them, ( -lnewlib) but the problem is still there. So, what's going on? Why can't ln find those functions in Sup32.lib? I KNOW they are there, I recompiled it myself to make sure! Pertinent (?) info: A500, Aztec 3.6a, using +L and precompiled headers. ln usage: ln +Q *.o -lsup32 -lc32 -O dme (from Makefile). Suplib version: Latest, from disk 285 or so... I know there have been some recent changes in suplib, but I don't think that's the cause. I'd appreciate any input from people who know how to get around this. Thanks. -val
dillon@overload.UUCP (Matthew Dillon) (06/06/90)
>In article <10034@chaph.usc.edu> bli@castor.usc.edu (Binary Logics) writes: >I am trying to get DME v1.30 (or so the doc file says) to compile on >my system, using Aztec 3.6a (still... :-) > >I can get it to compile fine, but at link time, it tells me that some >functions that should be in Matt's Suplib (and ARE!) are undefined. >They are _bzero, _bset, and _bmov. I'm not sure what's going wrong, but version 1.30 is *very* old !! I'm up to 1.40 (though apparently it is not completely stable so I'm waiting a bit before I send it off). In anycase, I've been removing all those old suplib dependancies... none of my new code uses suplib anymore and will all be compilable with the shareware DICE (my compiler system), so that should eradicate all these problems. -- -Matt Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
bli@castor.usc.edu (BLI CEO) (06/07/90)
In article <dillon.4160@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: > I'm not sure what's going wrong, but version 1.30 is *very* old !! I'm > up to 1.40 (though apparently it is not completely stable so I'm waiting > a bit before I send it off). > In anycase, I've been removing all those old suplib dependancies... none > of my new code uses suplib anymore and will all be compilable with > the shareware DICE (my compiler system), so that should eradicate all > these problems. Ok, thanks. I tried compiling 1.30 since it had all that I needed in it. (I even removed the Arexx stuff since I was gonna port it (for non-profit, private use, really ;-) to something with no REXX). Will wait for the first version without SupLib then. Thanks for the reply.
peter@sugar.hackercorp.com (Peter da Silva) (06/07/90)
In article <dillon.4160@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: > In anycase, I've been removing all those old suplib dependancies... none > of my new code uses suplib anymore and will all be compilable with > the shareware DICE (my compiler system), so that should eradicate all > these problems. Sounds good, but I hope you don't end up with a little Matt Dillon universe of programs that only work compiled with DICE. I'm sure you've got plenty of opportunity to test & compare against lattice and aztec, but I thought I'd give you a poke anyway... just in case, you know... -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ My other car is a hot-air balloon. v "Have you hugged your wolf today?" `-_-'
dillon@overload.UUCP (Matthew Dillon) (06/11/90)
>> of my new code uses suplib anymore and will all be compilable with >Sounds good, but I hope you don't end up with a little Matt Dillon universe of >programs that only work compiled with DICE. I'm sure you've got plenty of >opportunity to test & compare against lattice and aztec, but I thought I'd >give you a poke anyway... just in case, you know... >-- > _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. One of the main reasons for a parallel shareware distribution is to get rid of all the little compatibility problems and bugs before the commercial distribution. To whit, the shareware distribution is a pre-test. DICE currently has only standard ANSI functions and a few lattice-specific functions for compatibility (like getfnl). As far as non-portable compiler features go there are only two really: (1) The '_autoinit' storage class as part of a subroutine declaration automatically calls the subroutine from c.o (before _main), and (2) The automatic openning/closing of several standard libraries if you reference a base variable but do not declare it (the latter feature will be used mainly to support floating point via the amiga libraries and other items without requiring a single byte of extra code in c.o) I'll probably get a couple more shareware dists out before the commercial. For example, I've just completed new optimizations on logic and arithmatic operations that forward traverse through the expression tree, so an expression like: short a, b, c; a = (b + c) & (b ^ c); will generate code that uses word operations throughout instead of casting arguments to longs first (due to the storage being a short). Such optimizations make a huge difference in embedded C applications which use byte/word operations the majority of the time. -Matt -- Matthew Dillon uunet.uu.net!overload!dillon 891 Regal Rd. Berkeley, Ca. 94708 USA
dailey@frith.uucp (Chris Dailey) (06/15/90)
In article <dillon.4288@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: > a = (b + c) & (b ^ c); ^^^ A 'to the power symbol'? This isn't part of ANSI C. Is that a part of it? No complaints from me.. > Matthew Dillon uunet.uu.net!overload!dillon -- /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) C oo dailey@(cpsin1.cps|frith.egr).msu.edu (make WP5.1 for the Amiga) _( ^) "I am thankful for one leg. To limp is no disgrace -- / ~\ I may not be number one, but I can still run the race." -from B.C.
guineau@wjg.enet.dec.com (06/15/90)
[Matt's comments on DICE ommited] Matt, how about adding lots of Unix emulation like fstat() and ioctl() and how about a *real* fork()?!? --- W. John Guineau guineau@wjg.enet.dec.com Digital Equipment Corporation Marlboro MA. 01752
aca@nyit.UUCP (Al Arthur) (06/16/90)
In article <1990Jun14.172613.25768@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes: >In article <dillon.4288@overload.UUCP> dillon@overload.UUCP (Matthew Dillon) writes: >> a = (b + c) & (b ^ c); > ^^^ >A 'to the power symbol'? This isn't part of ANSI C. Is that a part of >it? No complaints from me.. The `^' character *IS* part of ANSI C, and original K&R C. It is the bitwise exclusive-or operator (ie. a^b means... either a, or b, but not both). In this case (out of context), the result of b^c is the union of bits in both, less the intersection of the two. Hope this helps, Al. > /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) -- Alex Arthur, System Programmer/UUCP Administrator New York Institute of Technology - Computer Graphics Laboratory Gerry House, Old Westbury, New York 11568 Phone:(516) 686-7644 UUCP: ...!{sbcs.sunysb.edu,philabs}!nyit!aca
ewing@se-sd.SanDiego.NCR.COM (David Ewing) (06/16/90)
>> a = (b + c) & (b ^ c); > ^^^ >A 'to the power symbol'? This isn't part of ANSI C. In C , ^ is the bitwise exclusive or operator. -- ---------------------------------------------------------------------- Dave Ewing "Act like a dumbshit and they'll ewing@se-sd.sandiego.ncr.com treat you like an equal." ----------------------------------------------------------------------