peter@sugar.hackercorp.com (Peter da Silva) (05/26/91)
OK, ENOUGH is ENOUGH. I'm sick of burning the midnight oil doing Manx conversions of Lattice programs (and getting ticked off at Lattice for not following the ANSI spec all the way). I'm sure other people are doing the same thing in reverse and getting ticked off at Manx for some of their more outre' function calls (fexec, for example). Hows about some of us get together and write a couple of libraries that automate this? We'd also need blink--make and make--blink tools, and something to convert Lattice's __chip declarations and Manx' #pragmas. Alternatively, we could hold some Manx and SAS emplyees to ransom until they bury the hatchet... :-> -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
davewt@NCoast.ORG (David Wright) (05/27/91)
In article <1991May26.022108.7901@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >conversions of Lattice programs (and getting ticked off at Lattice for >not following the ANSI spec all the way). I'm sure other people are doing They do much more so than Manx, who only recently added any kind of ANSI compliance. I don't use many esoteric features of the ANSI standard, but I have yet to find something that SAS/C does incorrectly. >Hows about some of us get together and write a couple of libraries that >automate this? We'd also need blink--make and make--blink tools, and something >to convert Lattice's __chip declarations and Manx' #pragmas. > >Alternatively, we could hold some Manx and SAS emplyees to ransom until >they bury the hatchet... :-> Or even more alternatively, you could just have people throw Manx C into the circular file (where IMHO it has belonged for more than 3 years) ASAP :-) (For the humour impared: :-)) What can you say about a C compiler that produces non-standard object modules so you can't link with modules produced with other languages? I have been able to link in AL modules created with a wide variety of assemblers, modules from a version of Forth, modules from Draco, and modules from a couple of other languages with Lattice/SAS C since day one. You can't say the same thing for Manx. For me, the question is: Why in this day and age would anyone continue to BUY the Manx compiler? (no :-)) Dave
bj@cbmvax.commodore.com (Brian Jackson) (05/27/91)
In article <1991May26.172439.2021@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >What can you say about a C compiler that produces non-standard object modules >so you can't link with modules produced with other languages? I have been able >to link in AL modules created with a wide variety of assemblers, modules from >a version of Forth, modules from Draco, and modules from a couple of other >languages with Lattice/SAS C since day one. You can't say the same thing >for Manx. For me, the question is: Why in this day and age would anyone >continue to BUY the Manx compiler? (no :-)) > Dave If you say so. 1. Because it's a good compiler. 2. Personal preference. Despite the fact that I am pretty much up to my neck in SAS stuff here, I still prefer The Aztec compiler and I use it over SAS for almost all my personal projects. 3. For most peole there is minimal need to link with Forth modules. I agree that Blink object module compatibility would be nice but it's pretty easy to do most anything you'd want to do and never ever have to stare at a convoluted BLINK line or arcane pragma. (And I suspect the number of people needing Draco compatibility is even smaller than the Forth community :) <<- not a slam on either langauge, btw :)) 4. The idea of having only one compiler company in the game does not make me smile at all. I think it's fair to say that the competition between Manx and SAS (nee Lattice) did nothing but good for both of the Amiga compilers (and therefore the Amiga users.) 5. Multiple thought paths. Independant developers will come up with different solutions to a problem. Some work better than others. The good solutions often end up in both products (this process was very evident in the heyday of the Aztec/Lattice competition.) Brian ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "Sometimes the hamster falls asleep in the little wheel." | -----------------------------------------------------------------------
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/27/91)
davewt@NCoast.ORG (David Wright) writes: >In article <1991May26.022108.7901@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>conversions of Lattice programs (and getting ticked off at Lattice for >>not following the ANSI spec all the way). I'm sure other people are doing > They do much more so than Manx, who only recently added any kind of >ANSI compliance. I don't use many esoteric features of the ANSI standard, What do you call recently? the ANSI standard wasn't finalized until may of '90 and Manx gave full ANSI in january of '90, with an update in june to fix things that changed in the finalization. that isn't "recent" (a year and a half ago?) anybody claiming an ANSI compliant compiler before may was working of of a draft proposal, and most of them haven't updated their compilers to that point since it was finalized. >but I have yet to find something that SAS/C does incorrectly. >>Hows about some of us get together and write a couple of libraries that >>automate this? We'd also need blink--make and make--blink tools, and something >>to convert Lattice's __chip declarations and Manx' #pragmas. >> >>Alternatively, we could hold some Manx and SAS emplyees to ransom until >>they bury the hatchet... :-> > Or even more alternatively, you could just have people throw Manx C >into the circular file (where IMHO it has belonged for more than 3 years) >ASAP :-) > (For the humour impared: :-)) >What can you say about a C compiler that produces non-standard object modules >so you can't link with modules produced with other languages? I have been able Manx's object modules are not a problem if you use Manx's linker. the Manx linker has an option to link standard Amiga object modules in with the Manx ones. Manx uses their object modules format to standardize all their comilers together, for instance, you can use a module generated on a Mac and link it into your amiga module as long as no system dependencies are involved. *I* like that option much more, because you can have people working on the same program for different machines WITHOUT having to give out your source code for common modules. >to link in AL modules created with a wide variety of assemblers, modules from >a version of Forth, modules from Draco, and modules from a couple of other >languages with Lattice/SAS C since day one. You can't say the same thing >for Manx. For me, the question is: Why in this day and age would anyone >continue to BUY the Manx compiler? (no :-)) > > > Dave .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
peter@sugar.hackercorp.com (Peter da Silva) (05/27/91)
In article <1991May26.172439.2021@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > In article <1991May26.022108.7901@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >conversions of Lattice programs (and getting ticked off at Lattice for > >not following the ANSI spec all the way). I'm sure other people are doing > They do much more so than Manx, who only recently added any kind of > ANSI compliance. I don't use many esoteric features of the ANSI standard, > but I have yet to find something that SAS/C does incorrectly. Well, I'm trying to convert a program full of things like: int a(char b, float c); ... int a(b, c) char b; float c; These are not compatible declarations. Because of the promotion rules, the latter is equivalent to: int a(int b, double c); > Or even more alternatively, you could just have people throw Manx C > into the circular file (where IMHO it has belonged for more than 3 years) > ASAP :-) And in a year or so the shoe will be on the other foot. Both compilers have been the obvious best choice at different times. Right now they're pretty much a tossup. > What can you say about a C compiler that produces non-standard object modules > so you can't link with modules produced with other languages? What can you say about a C compiler that doesn't use a standard makefile compatible linker? With Manx I can port UNIX C code pretty much straight. This is a "quality of implementation" issue, but isn't that the point? As for standard object modules, Manx switched over years ago. When it was originally written, the standard module handling tools were pretty damn primitive. They made a judgement call, got it wrong, and fixed it. When is SAS going to let me type "ln *.o -o program -lc"? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
griffin@frith.egr.msu.edu (Danny Griffin) (05/28/91)
>davewt@NCoast.ORG (David Wright) writes: >>but I have yet to find something that SAS/C does incorrectly. How about a simple floating point call that crashes your program because the stack is popped for values that were never stored there? -- Dan Griffin griffin@frith.egr.msu.edu
cg@ami-cg.UUCP (Chris Gray) (05/28/91)
In article <1991May27.125456.27018@sugar.hackercorp.com> peter@sugar.hackercorp.com writes: >Well, I'm trying to convert a program full of things like: > > int a(char b, float c); > > ... > > int a(b, c) > char b; > float c; > >These are not compatible declarations. Because of the promotion rules, the >latter is equivalent to: > > int a(int b, double c); Hmm. I seem to recall that the presence of an ANSI prototype for a given function would convert a following old-style definition of the function into the given ANSI form. Thus, in the above, it would be just the same as if the function definition had been int a(char b, float c) { ... I believe this was done so that people could phase-in ANSI-fication by building header files that supply prototypes for all of their functions, and thus having an easy way to get the protection of prototypes. I may be out of date on this, however. I remember it because the C compiler I was writing at the time didn't manage it (it's since been updated by others). -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA
billc@cryo.UUCP (William J. Coldwell) (05/28/91)
In article <1991May26.172439.2021@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <1991May26.022108.7901@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>conversions of Lattice programs (and getting ticked off at Lattice for >>not following the ANSI spec all the way). I'm sure other people are doing I'm one of those "other" people ;-). >>Alternatively, we could hold some Manx and SAS emplyees to ransom until >>they bury the hatchet... :-> This is a great idea, though I'm leaning toward just holding SAS people. >For me, the question is: Why in this day and age would anyone >continue to BUY the Manx compiler? (no :-)) 'Cause SAS _WON'T_ support the '040 until their 6.0 version is available sometime in the first half of 1992. (no ;-) either). 'Cause SAS is generating bad code on some of the more important things that I am doing, to which Manx works just fine. I can't wait 'till '92 - can you? > Dave -- William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you Amiga Attitude Adjuster BIX: wjcoldwell like to be a 3-DPro2 ? Cryogenic Software UUCP:billc@cryo 3-D PROFESSIONAL 2.0 #define STD_DSCLMR "The above opinions are mine. You can't have them."
jay@deepthot.cary.nc.us (Jay Denebeim) (05/28/91)
In article <1991May27.125456.27018@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >When is SAS going to let me type "ln *.o -o program -lc"? SAS's UNIX version does. On the Amiga, it uses the Amiga interface. Believe it or not AmigaDOS is NOT UNIX. When you're on the Amiga do things the Amiga way. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: UUCP: mcnc.org!deepthot.uucp!jay ====== Internet: jay@deepthot.cary.nc.us BBS:(919)-460-7430 VOICE:(919)-460-6934
ronald@ecl014.UUCP (Ronald van Eijck) (05/29/91)
In article <1991May26.172439.2021@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > Or even more alternatively, you could just have people throw Manx C >into the circular file (where IMHO it has belonged for more than 3 years) >ASAP :-) > (For the humour impared: :-)) >What can you say about a C compiler that produces non-standard object modules >so you can't link with modules produced with other languages? I have been able >to link in AL modules created with a wide variety of assemblers, modules from >a version of Forth, modules from Draco, and modules from a couple of other >languages with Lattice/SAS C since day one. You can't say the same thing >for Manx. For me, the question is: Why in this day and age would anyone >continue to BUY the Manx compiler? (no :-)) > > Dave Ever tought about the fact that people just like the manx c compiler over the lattice one. I'm not interrested in linking my c code with other languages except machine code and I can program that inline. So for me It's manx all the way and sas has to do a hell of a job convincing me to switch. BTW does sas have precompiled includes yet? -- +-------------------------------------------------------------------------+ | Ronald van Eijck {eunet!}hp4nl!cbmnlux!ecl014!ronald | | | | We do the impossible at once for a miracle we need a little more time | +-------------------------------------------------------------------------+
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/29/91)
In article <cg.0967@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes: In article <1991May27.125456.27018@sugar.hackercorp.com> peter@sugar.hackercorp.com writes: >Well, I'm trying to convert a program full of things like: > > int a(char b, float c); > > ... > > int a(b, c) > char b; > float c; > >These are not compatible declarations. Because of the promotion rules, the >latter is equivalent to: > > int a(int b, double c); Hmm. I seem to recall that the presence of an ANSI prototype for a given function would convert a following old-style definition of the function into the given ANSI form. Thus, in the above, it would be just the same as if the function definition had been int a(char b, float c) { ... This is what SAS did about it. Manx did it the way Peter described it. I think ANSI left the case undefined, so both compilers are "right." I prefer the way SAS did it - it makes building code that ports between prototyped & non-prototyped environments much more straightforward. <mike -- When logic and proportion have fallen softly dead, Mike Meyer And the white knight is talking backwards, mwm@pa.dec.com And the red queen's off her head, decwrl!mwm Remember what the dormouse said.
markv@kuhub.cc.ukans.edu (05/29/91)
>>Well, I'm trying to convert a program full of things like: >> >> int a(char b, float c); >> int a(b, c) >> char b; >> float c; >> >>These are not compatible declarations. Because of the promotion rules, the >>latter is equivalent to: >> >> int a(int b, double c); > > Hmm. I seem to recall that the presence of an ANSI prototype for a given > function would convert a following old-style definition of the function into Correct. ANSI says that promotion only occurs with old style declarations in the absence of a prototype. SAS does this, so does VAX C, MSC 5.1/6.0, Turbo C/C++/Borland C/C++, and cc on AIX. (These are the "only" ANSI compilers I've used :-)). If Manx promotes the parameters in the presence of a prototype, then it is Manx's error. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ahh@glyph.kingston.ny.us (Andy Heffernan) (05/29/91)
In article <1991May27.125456.27018@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: [...] > >When is SAS going to let me type "ln *.o -o program -lc"? That's the thing that always confused me about Manx -- one of the points that has always been bandied about in favor of their compiler is the Unix-like compiler tool-set they provide. OK, fine, that's cool... ...but naming the linker "ln" ??? $ ln *.o -o program -lc ln: -lc not found -- ------------------------------------------------------------------------- Andy Heffernan $BJ8;z(J uunet!glyph!ahh
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/29/91)
In article <4999@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >davewt@NCoast.ORG (David Wright) writes: >>In article <1991May26.022108.7901@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>... > >What do you call recently? the ANSI standard wasn't finalized until may of >'90 and Manx gave full ANSI in january of '90, with an update in june to fix >things that changed in the finalization. that isn't "recent" (a year and a >half ago?) anybody claiming an ANSI compliant compiler before may was working >of of a draft proposal, and most of them haven't updated their compilers to >that point since it was finalized. Much of ANSI was standardized long before the final draft. Prototypes, for example. >>What can you say about a C compiler that produces non-standard object modules >>so you can't link with modules produced with other languages? I have been able > >Manx's object modules are not a problem if you use Manx's linker. the Manx >linker has an option to link standard Amiga object modules in with the Manx >ones. Manx uses their object modules format to standardize all their comilers Unfortunately, they are a problem. It forces you to use Manx's linker which is braindamaged... actually, *all* linkers are braindamaged, so you have to use the one that fits the mixed-language project. Unfortunately, with Manx C you *MUST* use Manx's linker. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
swalton@corona.csun.edu (Stephen Walton) (05/29/91)
In article <1991May28.165437.31104@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >>>Well, I'm trying to convert a program full of things like: >>> >>> int a(char b, float c); >>> int a(b, c) >>> char b; >>> float c; >>> >>>These are not compatible declarations. > >Correct. ANSI says that promotion only occurs with old style >declarations in the absence of a prototype. Sorry, no. Harbison and Steele, Third Edition, section 9.2.2, pages 242 ff. discusses this at length. The relevant sentence is rule 4 on page 244: "A function type declared in protoype form is compatible with a non-prototype function definition if: ... 4. the type of the i'th parameter in the prototype is compatible with the type resulting from the applying the usual argument conversions to the i'th parameter in the definition." Specifically, H&S state that the only prototype compatible with the definition "int f(x, y) float x; int y; {...}" is "extern int f(double x, int y)". "extern int f(float, int)" is specifically not acceptable. -- Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge "Lately it occurs to me/What a long, strange trip it's been"
peter@sugar.hackercorp.com (Peter da Silva) (05/29/91)
In article <cg.0967@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes: > Hmm. I seem to recall that the presence of an ANSI prototype for a given > function would convert a following old-style definition of the function into > the given ANSI form. Well, Lattice may do that but that's not what the ANSI standard says. I've been back and forward on this in comp.std.c enough times to be convinced that this is a violation of the current standard. Since Lattice's ANSI compiler came out before the standard was finished, I'm not surprised. No less a pair than Brian Kernighan and Dennis Ritchie were caught out in a couple of places in K&R 2. But I'm glad Manx waited until it was final. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/29/91)
In article <jay.1517@deepthot.cary.nc.us> jay@deepthot.cary.nc.us (Jay Denebeim) writes: > SAS's UNIX version does. SAS's UNIX version has nothing to do with the Amiga version. It predates SAS swallowing Lattice. > On the Amiga, it uses the Amiga interface. > Believe it or not AmigaDOS is NOT UNIX. When you're on the Amiga > do things the Amiga way. Not good enough. Then why can't I say: link from *.o to progname lib c It's not the command line syntax that causes a problem, it's the fact that you can't pass all your filenames on the command line. You know, one of the neat things about C is that it's pretty easy to write portable programs. So why does Lattice have to make it so hard to write portable Makefiles? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/29/91)
In article <billc.3366@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: > >'Cause SAS _WON'T_ support the '040 until their 6.0 version is available >sometime in the first half of 1992. (no ;-) either). 'Cause SAS is >generating bad code on some of the more important things that I am doing, >to which Manx works just fine. I can't wait 'till '92 - can you? > Last time I checked SAS/C had an option to generate 040 specific code. Now, how well optimized it is for the 040 is another question, but it would seem that they do support it. Are you saying that they tried to support it but it is broken? (not like I have an 040 Amiga to try it on) Also, AmigaWorld Tech Journal had an interesting article comparing the two. They timed several different programs, benchmarks of a wide variety, and SAS came out on top almost every time. Often by big margins. >> Dave > >-- > William J. Coldwell PLink: CRYO I'm a 3-DPro, wouldn't you > Amiga Attitude Adjuster BIX: wjcoldwell like to be a 3-DPro2 ? > Cryogenic Software UUCP:billc@cryo 3-D PROFESSIONAL 2.0 > #define STD_DSCLMR "The above opinions are mine. You can't have them." Now the world has gone to bed, Now I lay me down to sleep, Darkness won't engulf my head, Try to count electric sheep, I can see by infrared, Sweet dream wishes you can keep, How I hate the night. How I hate the night. -- Marvin
davewt@NCoast.ORG (David Wright) (05/30/91)
In article <ronald.3706@ecl014.UUCP> ronald@ecl014.UUCP (Ronald van Eijck) writes: >BTW does sas have precompiled includes yet? Yes, and has since version 5.0. Dave
jesup@cbmvax.commodore.com (Randell Jesup) (05/30/91)
In article <billc.3366@cryo.UUCP> billc@cryo.UUCP (William J. Coldwell) writes: >'Cause SAS _WON'T_ support the '040 until their 6.0 version is available >sometime in the first half of 1992. (no ;-) either). 'Cause SAS is >generating bad code on some of the more important things that I am doing, >to which Manx works just fine. I can't wait 'till '92 - can you? '040 support?? There's only one user-level instruction that was added: Move16, and that one requires a NOP either before or after it in the currently available mask revs, if I remember right. Perhaps you mean FP that uses inline for instruction that are in the CPU, and calls subroutines directly for things that are emulated. That's all I can think of. Also, on what released '040 board would they test it? I take it 5.10a has a bug that's affecting you? I assume you've notified them - they're pretty good about support, and also provide good support on BIX (a number of their programmers are regulars there, and answer questions in their support conference). I don't mean by any of this that Manx is bad. I actually like the see-saw and interplay of ideas caused by the competition, and Dice should help in this too. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
jesup@cbmvax.commodore.com (Randell Jesup) (05/30/91)
In article <1991May29.102703.6216@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Not good enough. Then why can't I say: > > link from *.o to progname lib c > >It's not the command line syntax that causes a problem, it's the fact that you >can't pass all your filenames on the command line. Both BLink and it's predecessor, Commodore's ALink, allow the objects on the command line. Note, however, that there's often a maximum command-line length that gets in the way, unlike most unixes (though I've seen them have problems at times). That length restriction is starting to be eased in 2.0, but it's still not gone. Blink from $(OBJS) to foo lib $(LIBS) $(LINKOPTS) Even between unix variants, you often have to have different makefiles, let alone different OS's. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
peter@sugar.hackercorp.com (Peter da Silva) (05/31/91)
In article <dillon.8071@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > Unfortunately, they are a problem. It forces you to use Manx's linker > which is braindamaged... actually, *all* linkers are braindamaged, so > you have to use the one that fits the mixed-language project. > Unfortunately, with Manx C you *MUST* use Manx's linker. Luckily, with the Amiga you don't need to use a linker on a mixed-language project. Just build Amiga shared libraries in the exotic languages and call them from a C skeleton. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.