c55-grig@buddy.Berkeley.EDU (Ted Griggs) (11/26/86)
[] I discovered the bug! (note "the" not "my") I was compiling and assembling the program under Manx (tried both 16 & 32 bit ints..neither had a chance at working). I sadly had to compile and assemble it with Lattice 1.0? to make it work. My complaint with C on the Amiga is that of the two compilers: 1) Lattice has 2 100K compilers and the slowest linker I have ever seen, and 2) Manx compiles fast, link fast, and produces small code but on many occasions produces incorrect code. I have heard Lattice came out w. version 3.?? and a much faster linker. I hope that this is true. Ted Griggs zen!buddy!c55-grig
cmcmanis@sun.uucp (Chuck McManis) (11/26/86)
In article <1133@zen.BERKELEY.EDU>, c55-grig@buddy.Berkeley.EDU (Ted Griggs) writes: > > ... edited stuff about bugs and such ... > My complaint with C on the Amiga is that of the two compilers: 1) Lattice > has 2 100K compilers and the slowest linker I have ever seen, and 2) Manx > compiles fast, link fast, and produces small code but on many occasions > produces incorrect code. > I have heard Lattice came out w. version 3.?? and a much faster linker. > I hope that this is true. > Yes it is true, I sent in my Lattice Update card and got my new compiler on Monday. (about three weeks after they announced it on BIX) The update cost $75, and included a new manual and the Lattice Text Management utilities (grep, wc, splat, file, etc) All I need say is "get the update!" Some initial reactions : * New stuff with the compiler includes the TMU package as mentioned above, a macro assember called asm (not MetaCompCo compatible), Blink 6.7 (that wonderfully fast Alink compatible linker), and a completely rewritten frontend 'lc'. New documentation includes the TMU manual and a new compiler manual that is spiral bound (yea!) and more complete. Oh, and a zillion new library routines are available too. * Two things strike you about the compiler when you use it, first it is much faster, and second the user interface is a lot 'cleaner'. * New options to the lc command are -M to recompile only those files that have been modified, and -L which automatically invokes the linker when all compiles complete successfully. The compiler still doesn't recognize control C during the phases, but if one of the modules in a multimodule compile fails to compile you are given the option to exit. * Two library routines that really stood out were the time routines (unix compatible time(), asctime()) and the wild card expansion routines for file names that can programmatically accept MS-dos type wild cards or Amiga wildcards. * And finally Fork() support. But only for programs that were originally C sources. BCPL programs don't fork. Highly reccomended. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
john13@garfield.UUCP (11/27/86)
[]
One problem I haven't seen mentioned (although if it is known and there is a
way around it, I'd like to hear about it!):
Manx printf doesn't like %f!
main()
{ float x=1;
printf("%f\n",x); }
causes an "f" to be printed when I run it through Manx. This problem cropped up
recently again, and I thought that it had happened before only when using 16
bit ints; however, when I used "+l" and c32.lib, it still wouldn't work.
Now I do have programs written where it *does* work, scanf's and printf's with
%f's all over the place. But I remember having problems with them then too, and
having to use +l to get them to work (which was of no help the other night).
The last several times that this has happened to me, I've always been a bit
tight for memory (about 145K free before invoking compiler), but I can't see
why that should make a difference, and even if that is the reason, it's still
a pretty strange bug.
The Manx documentation had nothing to say about this, other than that it
supported full Kernighan & Richie, and that double precision variables take
up 64 bits although only 32 are used. Kernighan & Richie also says %e is an
alternate floating point specifier, but using that just changed the "f" to
an "e" when the program was run. I also tried various combinations of
double, "%lf", "%le", cc +l, ln -lc32, etc, without success. When using "%lf"
it would accept the "l", but still print the "f", not take it as a parameter.
Thanks for any help!
Johnjohn13@garfield.UUCP (11/28/86)
In article <3060@garfield.UUCP> john13@garfield.UUCP (me) writes: > >main() >{ float x=1; > printf("%f\n",x); } > as an example of an improperly running program. It's since been pointed out to me that technically this *should not* work, on a C compiler that plays by the rules: it will try to assign the integer value 1 to a floating point number. This has never caused me any problems with Lattice, or with the compiler on our Unix system, and so I wasn't aware of it (haven't seen it in Kernighan and Ritchie either). So main() { float x = 1.0; printf("%f\n",x); } should work, right? Wrong! I tried this too and again it just printed the letter f. So please, no flood of replies saying "force it to float with a decimal point!". John
root@sbcs.UUCP (Root) (11/28/86)
Chuck, Gee, the C compiler I am using for my Amiga is sooo bad - in fact it is made by your company. Seriously, the Sun C compiler produces good, correct code for either 68000/68010/68020's. All one has to do to use it is to rewrite a few multiply/divide routines, and get/write a C library (Manx commercial version comes with lib source, right?). I have been doing development using a system similar to this for several months now, and am convinced that cross development is the _only_ way to go for serious development. If memory serves, I believe I read somewhere that Amiga does their development using the (expensive) GreenHills compiler system that also runs on a SUN. Why suffer the slings and arrows of Manx, Lattice, etc if you have access to a Sun workstation?? Rick Spanbauer
hull@hao.UUCP (Howard Hull) (11/30/86)
In article <3060@garfield.UUCP>, john13@garfield.UUCP writes: > Manx printf doesn't like %f! > > main() > { float x=1; > printf("%f\n",x); } > > causes an "f" to be printed when I run it through Manx. Try using the linker string ln garbage.o -lm -lc -o a.out instead of ln garbage.o -lc -lm -o a.out you'll be amazed what a difference it makes. If you are doing 32 bit ints, of course you'll use -lm32 -lc32 for the libraries. Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull
phils@tekigm.UUCP (Phil Staub) (11/30/86)
In article <3060@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >One problem I haven't seen mentioned (although if it is known and there is a >way around it, I'd like to hear about it!): > >Manx printf doesn't like %f! > He goes on to describe the problem and what he has tried to do to fix it. Then: >The Manx documentation had nothing to say about this, other than that it >supported full Kernighan & Richie, Have you looked at page 6 of the 3.20a release document, (mine is dated March 3, 1986. I think thats probably the only one you'll find for 3.20a). I won't go into detail, but you have to use the m.lib or m32.lib library, and it must be searched before the c.lib or c32.lib library, e.g.: ln file.o -lm -lc Hope this helps. Phil Staub P.O. Box 3500 Tektronix, Inc. Vancouver, Washington 98668 ISI Engineering M/S C1-904, (206) 253-5634 ..tektronix!tekigm!phils -- Phil Staub P.O. Box 3500 Tektronix, Inc. Vancouver, Washington 98668 ISI Engineering M/S C1-904, (206) 253-5634 ..tektronix!tekigm!phils
papa@bacall.UUCP (Marco Papa) (12/01/86)
> In article <1133@zen.BERKELEY.EDU>, c55-grig@buddy.Berkeley.EDU (Ted Griggs) writes: > > > > ... edited stuff about bugs and such ... > > My complaint with C on the Amiga is that of the two compilers: 1) Lattice > > has 2 100K compilers and the slowest linker I have ever seen, and 2) Manx > > compiles fast, link fast, and produces small code but on many occasions > > produces incorrect code. ^^^^^^^^^ Yes, it is DEFINITELY true! We bought MANX C and recompiled A-Talk. Code size went down from 145K (lattice C 3.03) to 99K (MANX 3.20a). The problem is that when we sent the new version out to the beta testers we received complaints of GURU meditations on the MANX version. This is with code that works perfectly with Lattice, and we used the 32-bit integer option which is supposed to allow complete porting of programs that use 32-bit integers and libraries. We also tried beta MANX 3.30c but this version has at least as many bugs as the current commercial version (3.20a). Telephone calls to MANX tech support always result in "we will be coming out with the new update in the fall", "maybe next month". We have ba
rmariani@watmum.UUCP (12/01/86)
In article <3061@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: > >main() >{ float x=1; > printf("%f\n",x); } > >should work, right? Wrong! I tried this too and again it just printed the >letter f. So please, no flood of replies saying "force it to float with a >decimal point!". > >John Once you know all the details, this isn't really a problem, it's a feature. In the runtime libraries, a large amount of the code to do a printf is associated with printing formatted floating point numbers, however, this code is not always used (I hardly ever use floating point in my C programs for instance). Thus there are two versions of printf, one which doesn't have the floating point code in it (that's the one in c.lib and c32.lib) and one with the floating point code (m.lib and m32.lib (have I got those names right? Well the math libraries... whatever they're called). To get the version with the floating point in it, simply link with m.lib. Make sure that it is first in the list of libraries (or before c.lib anyway) otherwise you'll get the no %f version that's in the other library. Like I said this is a feature (It's documented! Read the manual! All of it! ) It makes many programs quite a bit smaller... -Rico
gary@mit-eddie.MIT.EDU (Gary Samad) (12/01/86)
In article <3060@garfield.UUCP>, john13@garfield.UUCP writes: > [] > One problem I haven't seen mentioned (although if it is known and there is a > way around it, I'd like to hear about it!): > > Manx printf doesn't like %f! One of the ways that Manx has cut down the minimum size of a program is by cutting the %f handling out of the standard printf in the c library. To get %f handling back, simply link with -lm BEFORE your -lc in your link statement. This will bring in a different copy of printf that DOES handle %f! by the way, the -lm means "link with the math library" where the other printf is kept. Gary
rokicki@navajo.STANFORD.EDU (Tomas Rokicki) (12/09/86)
In article <245@sbcs.UUCP>, root@sbcs.UUCP (Root) writes: > If memory serves, I believe I read somewhere that Amiga > does their development using the (expensive) GreenHills compiler system > that also runs on a SUN. Why suffer the slings and arrows of Manx, > Lattice, etc if you have access to a Sun workstation?? > Rick Spanbauer Depends on your application. For development, I *want* the smaller and faster code that using 16-bit ints allows. Manx with 16-bit ints still generates code far smaller than on any 68000 compiler I have run across, including the Sun and Greenhills compiler. Also, Manx is a nice enough system that development on the machine is less painful than downloading stuff to test. -tom
cmcmanis@sun.uucp (Chuck McManis) (12/09/86)
In article <245@sbcs.UUCP>, root@sbcs.UUCP (Root) writes: > ... If memory serves, I believe I read somewhere that Amiga > does their development using the (expensive) GreenHills compiler system > that also runs on a SUN. Why suffer the slings and arrows of Manx, > Lattice, etc if you have access to a Sun workstation?? > > Rick Spanbauer Well, for one thing my Amiga is at home and my Sun Workstation is at work. (Which would really cut into the compile/test time) And second because obviously Sun doesn't pay me to do Amiga programs, when I use this 50K workstation I try to maximize the benefit to my employer. Now if I could buy a Workstation for use at home, why would I want an Amiga? -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
miner@ulowell.UUCP (Richard Miner) (12/10/86)
In article <245@sbcs.UUCP> root@sbcs.UUCP (Root) writes: (Talks about a Sun development environment) >...development using a system similar to this for several months now, and >am convinced that cross development is the _only_ way to go for serious >development. Why suffer the slings and arrows of Manx, >Lattice, etc if you have access to a Sun workstation?? > Rick Spanbauer A few months ago I would have agreed with you Rick, but today I think the ideal Amiga development environment would be native: A turbo Amiga w/2.5meg, just about as fast as the new Sun/Apollo workstation and much faster then older models; The latest Manx or Lattice compiler, they are both shaping up quite well; hard disk; Ethernet and NFS, or ArcNet (call Ameristar in NJ); A recoverable ram disk ,I wish I could get Perrys over the self for my C-Ltd ram; Zorro expansion box for ethernet, memory, 68020, and home grown hardware; And the most important ingrediant, a second Amiga to test your code on so your development machine does not have to be rebooted after each compile when you visit the Guru. All of this equipment is still less then a Sun or Apollo, and look at all the toys you get to play with! In addition to the above being close to a Sun environment of today; as soon as source level debuggers are around for Manx or Lattice C the Amiga will become even more attractive. Don't get me wrong, I think Suns and Apollo's are great workstations I use them both and am trying to them and my Amiga's all talking. I would rather do Amiga specific development on the Amiga. To bad they can't programmed at a more abstract level. Just call OpenLibrary on all of them, forget CrossCompiling they could be object compatable; This is getting longer then I want to but one last note. The ideal developmet enviroment in the eyes of EA, as presented at the developers conference in thier talk "Developing a Workstation Environment", was a 10MHz IBM-AT :-( . Its worked for them but ugg... -- Rich Miner ...!wanginst!ulowell!miner ULowell, Center for Productivity Enhancement (617) 452-5000 x2693 HAL hears the Amiga9000 series is not selling. "Please explain Dave. Why aren't Amiga9000's selling?" Bowman hesitates, "You aren't IBM compatible."
higgin@cbmvax.UUCP (12/11/86)
In article <3060@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >One problem I haven't seen mentioned (although if it is known and there is a >way around it, I'd like to hear about it!): > >Manx printf doesn't like %f! > >main() >{ float x=1; > printf("%f\n",x); } > >causes an "f" to be printed when I run it through Manx. >... >Thanks for any help! > >John This may have already been answered (I've been off the net for over a week), but I think your problem is that you're not linking to m.lib FIRST. There are two versions of printf in the Manx libraries, and the one you want (which supports printing floating point numbers) is in m.lib. The other is in c.lib and doesn't support floating point and so is much smaller. Since not all programs need floating point, this setup is smart, but it requires that if you want the floating point version of printf() you must link as follows: ln foo.o -lm -lc NOTE: -lm comes first to force the linker to resolve the external reference of printf in foo.o in m.lib and not c.lib. Hope this helps, Paul. Disclaimer: I work for myself, and my opinions are my own.