toma@tekgvs.LABS.TEK.COM (Tom Almy) (06/29/90)
I bought the upgrade, and then read this group. While I'm not happy with the C orientation of V2.00 (mainly because the 8086 is a lousy machine for a C implementation, and much better for Modula-2 or Pascal which can effectively handle segments) the complaint about missing "C language sources" is blatently false. The TS languages use a common core of i/o routines which, while having names suspiciously like stdio, are written in assembler. The older FIO package was much more elegant IMHO, but this is the only way to mix languages. The files in question are r_core.a and r_mcore.a. The new package actually comes with a more complete set of sources than the old one did. Everything is there now that they supply the mathlib sources. The "competition" always leaves out the math library and the graphics library sources. The very sophisticated (yet easy to use) "make" facility and the ability to use DLLs in MS-DOS makes this the most sophisticated package around. If their coming C++ and existing C compilers provide as much sophistication I would be likely to toss my Borland and Microsoft compilers (I already tossed my Zortech). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
RCAPENER@cc.utah.edu (07/03/90)
In article <7734@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > I bought the upgrade, and then read this group. While I'm not happy with > the C orientation of V2.00 (mainly because the 8086 is a lousy machine for > a C implementation, and much better for Modula-2 or Pascal which can > effectively handle segments) the complaint about missing "C language sources" > is blatently false. > Jimminy Crickets! Is that why they use C to write almost all of the software for IBM RS/6000, the Motorola 88000 based machines (DG Aviion and Tektronix WS)? Hmm, I wonder why C works so well on those machines that have segmented architectures. Perhaps it could be that they are workstations while the lowly 8086 is only used in a PC 8^)? Or maybe the fact that the majority of the compilers out there are written in C (ok, so some of them are still written in Assembler) means that they are also using the wrong language 8-)). I delight in pulling the tiger's tail 8^))).
steve@robobar.co.uk (Steve Bleazard) (07/05/90)
In article <75055@cc.utah.edu> RCAPENER@cc.utah.edu writes: >In article <7734@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM >(Tom Almy) writes: >> I bought the upgrade, and then read this group. While I'm not happy with >> the C orientation of V2.00 (mainly because the 8086 is a lousy machine for >> a C implementation, and much better for Modula-2 or Pascal which can >> effectively handle segments) the complaint about missing "C language sources" >> is blatently false. >> > >Jimminy Crickets! Is that why they use C to write almost all of the >software for IBM RS/6000, the Motorola 88000 based machines (DG Aviion >and Tektronix WS)? Hmm, I wonder why C works so well on those machines >that have segmented architectures. Perhaps it could be that they are >workstations while the lowly 8086 is only used in a PC 8^)? The reasons for choosing C as the implementation language are often entirly divorced from the architecture of the machine. Where unix is the OS there is no choice, other languages are either not available or poorly implemented / supported (eg Logitech stopped selling and supporting MODULA-2 for Xenix). This may be changing, but as of today C is the best bet for unix machines. With other OS's it depends on your OS / machine; in the MSDOS world Modula-2 is an excellent choice (IMHO), on a CDC 6600 FORTRAN and so on. The choice of language must, in part, be guided by the level of support for the language. Also, in all too many cases, C is chosen because 'everyone else uses C', Tom Almy's point about the suitablity of C for a segmented architecture like that of 8086 (and 80x86's in real mode) family is entirely valid. First, it is important to stress that the following is only applicable when attempting to write large applications on such an architecture (in this context large is defined as a code or data size > segment size). C does not encourage modularization of code in the same way Modula-2 does, in particular a single Modula-2 module can be compiled into one segment (assuming it's small enough) and only the functions that are exported and imported need be called using far calls. Likewise with the data, data is local unless exported, each module can have it's own data segment. Now C people would say, "but we can do that too, just stick static infront of all the local functions and variables". The problem is that this is not the default and in general, usually because of programmer laziness, all functions end up being global. To summarize, Modula-2's Modules, are better suited to compilation into seperate segments than C's compilation units (files). >I delight in pulling the tiger's tail 8^))). > Careful, the head may turn round and bite :-) >Or maybe the fact that the majority of the compilers out there are >written in C (ok, so some of them are still written in Assembler) Most compilers out there are not written in C, most C compilers are written in C (not all - I beleive Topspeed C is written in Modula-2). A few of the older compilers are written in assembler (most notably Borlands TurboPascal for CP/M (remember CP/M!)). The rest are written in a very mixed bag of languages, depending on there age and the manufacturer. C, despite its age, is a relatively new language. Very little programming, outside unix, was done in C even 10 years ago. Now every man and his dog has a C compile Steve -- Steve.Bleazard@RoboBar.Co.Uk | Phone: +44 81 991 1142 x153 Snr Software Engineer, Robobar Ltd. | Fax: +44 81 998 8343 (G3) 22 Wadsworth Road, Perivale. | Middx., UB6 7JD ENGLAND. | ...!ukc!robobar!steve
randy@m2xenix.psg.com (Randy Bush) (07/05/90)
In <75055@cc.utah.edu> RCAPENER@cc.utah.edu writes: > I delight in pulling the tiger's tail 8^))). But it pays to do so with some foreknowledge. The JPI compilers under discussion are _all_ written in Modula-2. I wonder why. -- ..!{uunet,qiclab,intelhf}!m2xenix!randy randy@psg.com randy@m2xenix.uucp