mwm@violet.berkeley.edu.UUCP (01/16/87)
I vaguely recall that Manx 3.20 was going to start providing a compiler similar to what Lattice was shipping with their 3.03 (sorry, I *had* to say that; the reverse comment has been bothering me for a long time....): the v7 features of structure assignment (including the implied assignments with function arguments and return values), starting to provide ANSI-compatable functions (instead of BSD-compatable ones, sigh. ANSI went with SysV), and function prototyping. Can someone out there confirm this? Thanx, <mike
higgin@cbmvax.cbm.UUCP (Paul Higginbottom GUEST) (01/19/87)
In article <2229@jade.BERKELEY.EDU> mwm@violet.berkeley.edu(Mike Meyer) writes: $ $I vaguely recall that Manx 3.20 was going to start providing a $compiler similar to what Lattice was shipping with their 3.03 (sorry, $I *had* to say that; the reverse comment has been bothering me for a $long time....): the v7 features of structure assignment (including the $implied assignments with function arguments and return values), $starting to provide ANSI-compatable functions (instead of $BSD-compatable ones, sigh. ANSI went with SysV), and function $prototyping. Can someone out there confirm this? $ $ Thanx, $ <mike Why would Manx want to make their product SLOWER, LARGER, and REQUIRE lots of other programs like the one you posted in your next message (cc.c) to be "as good as" Lattice? I'm not sorry, I HAD to say that, too. Anyway, the upcoming upgrade for Manx users (3.40 I believe) has full structure assignment (including as function parameters and return values), and is apparently a lot closer to the ANSI standard. But with garbage like the automatic concatenation of strings in the ANSI standard, I wish it weren't! E.g:... char *strings[] = { "this", "is", "a" "test" }; Question: how many strings does the array contain? Answer: 3! Because a comma is missing after the "a", no error is generated, the next string is simply appended to it. This is apparently an ANSI standard (blah). The strchrs and such have been added on top of the standard v7 stuff (isn't duplication wonderful?). And most importantly, the code generator has been improved greatly. It's still not 100% if you decide to use a million register variables in one function, and 32 bit support still isn't perfect, but then there's no need to use the 32 bit stuff at all anyway. Paul. Disclaimer: the above opinions are my own.
mwm@eris.BERKELEY.EDU (Mike Meyer) (01/20/87)
In article <1250@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom GUEST) writes: >Why would Manx want to make their product SLOWER, LARGER, You can either get smaller & faster, or a nice set of features. I use GNU emacs, so you know what my tastes run to (and that's what it is, a matter of taste). I nearly bought MANX, until I found out they didn't even support a v7 C compiler. And according to you don't now, and won't until 3.40 (though I have other sources that say otherwise). >and REQUIRE >lots of other programs like the one you posted in your next message (cc.c) >to be "as good as" Lattice? I'm not sorry, I HAD to say that, too. Sorry, but Lattice no more requires a cc than Manx requires the version that Fred wrote for it. It just makes life easier if you're moving makefiles between Unix and the Amiga, no matter which compiler you're going to use. >anyway, the upcoming upgrade for Manx users (3.40 I believe) has full >structure assignment (including as function parameters and return values), >and is apparently a lot closer to the ANSI standard. But with garbage >like the automatic concatenation of strings in the ANSI standard, I >wish it weren't! E.g:... > >char *strings[] = { > "this", > "is", > "a" > "test" >}; Hmm - I thought they blew that off in favor of a string concatenation operator in the pre-processor; which version of the standard are you using? If it's there in the current draft, you should first check the rationale behind it, and if you think they're wrong, notify the standards committee. Otherwise, you have only yourself to blame if it's still there in the final version of the standard. And as bogus as the current standard is, it is going to improve the one thing that makes C worth using: the ability to move code between different compilers/environments. If only a modern language had the portability of C or FORTRAN (quit dreaming, mike!). >The strchrs and such have been added on top of the standard v7 stuff (isn't >duplication wonderful?). Sorry, but v7 didn't have anything like strchr/strrchr (index/rindex for berkeleyphiles). Ansi followed the AT&T library; you won't find any duplication there. You will find it in BSD libraries that have added the v7 stuff. Lattice doesn't fall into that category, though Manx will when they go to ANSI compatability. Of course, Lattice has lots of OTHER things that they had in their old compilers that are now duplicated in the name of ANSI. >And most importantly, the code generator has been improved greatly. It's >still not 100% if you decide to use a million register variables in one >function, and 32 bit support still isn't perfect, but then there's no need >to use the 32 bit stuff at all anyway. [Time for some MANX bashing. Those not interested in another round of compiler wars should skip this.] Gee, it seems that the people at Manx need to go back to school - they've forgotten one of the basic rules of programming: Make it RIGHT before you make it faster. Seems like they should quit working on making it smaller and faster, and worry about making it generate correct code. [End of MANX bashing.] Since I've got it in front of me, let me make the plug: The above rules of programming can all be found in one short book, Kernighan and Plauger's "The Elements of Programming Style." Recommended reading for *all* programmers, and re-reading it never hurts. Finally, there's a DAMN good reason for wanting the 32-bit stuff. Try porting anything from the "all the worlds a VAX, and every variables's a LONG" world of 4BSD (Note: this is rapidly being fixed; the bug reports on it from CSRG are filling my mailbox at an alarming rate). You'll quickly find out you need 32-bit ints. Of course, on a 68K family machines that predate the 68020, you really want both a 16-bit int and a 32-bit int version of the compiler; one for porting, and one for benchmarks (from the mouth of a major 68K computer manufacturer!). Manx got that right. <mike