rosenkra@Alliant.COM (Bill Rosenkranz) (09/13/88)
--- there has been a lot of discussion in the past regarding the huge cost of source for the minix c compiler. has gcc (the GNU c compiler) and possibly g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, this sounds like a very attractive alternative to the existing situation. if it has not been ported, can it be ported? gcc is available in a number of places (i know of UUCP access from osu-cis). gcc has already been ported to the atari ST (but it has more memory :^). it is BIG and this might be a problem on 640k systems. -bill
frank@morgan.com (Frank Wortner) (09/14/88)
Bill Rosenkranz <rosenkra@alliant.com> writes: >there has been a lot of discussion in the past regarding the huge cost of >source for the minix c compiler. has gcc (the GNU c compiler) and possibly >g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, >this sounds like a very attractive alternative to the existing situation. "Huge" is, in my opinion, an exageration. The source costs $99, not much more than the $89 that Minix itself costs. Admittedly, I have a steady, rather well-paying job, so I can fork over a hundred dollars without much pain. Other people may not be so lucky. Still, in comparison the cost of many other common bits of software and hardware -- two to three thousand dollars for a nice PC system comes to mind -- $99 is cheap. I also don't believe that GCC is "essentially free." There are a few hidden costs involved. First is media. If I want GCC, I will have to supply disks and/or tapes to someone who will make a copy for me. Next is a possible copying fee. Remember, the FSF license mandates that one give away software, but one can recover duplication costs. Even FSF charges a nominal -- actually $150, I believe -- fee per tape. Another cost is the price of computer time on a machine powerful enough to host GCC cross- development. Finally, there's the price of your time. Someone has to do the work. Perhaps some or all of these costs are nominal in some cases, but "free" is another matter. Even if all of these costs are reduced to zero, there is still the possibility, make that the probability, that GCC won't fit into the 64K per program limitation of "stock" IBM PC Minix. (Wow, ten years ago we all thought 64K was more memory than anyone would ever need!) GCC and GNU were not meant for "small" computers. This does not rule out cross compilers, but that's a frustrating and expensive way to play. Don't get me wrong. I'm not knocking GCC. Although I have no personal experience with it (yet), I'd be willing to bet that it's a good piece of work. It probably produces better code than the Minix ACK C compiler. The source is probably more useful. Minix C source does not include the tools used to generate tables for the table-driven front and back ends of the compiler, while a complete GCC distribution probably includes everything. The Minix C system is, in my opinion, a good buy for those who want to upgrade a 1.1 or earlier system, and for those who want a totally compatible cross compiler -- recompiling the source on a Sun or VAX is very easy. I've done both, and, to that degree, I've gotten my money's worth. For me, the ability to "plug in and play" was worth the cost. Frank " ... and he stepped down off his soap box, wondering if anyone near him had any overripe tomatoes ... "
paradis@encore.UUCP (Jim Paradis) (09/15/88)
Sorry, Bill, but in my opinion porting gnu-anything to MINIX is a real problem. Gnu software is essentially written for machines with 32-bit address spaces and virtual memory. Since MINIX on the PC currently only supports 16-bit split I&D addressing, almost any gnu program would be far too big to fit. MAYBE if someone could figure out a way to break the 64K barrier (we're not even talking the 640K barrier here yet!) then we can start talking about putting GNU stuff up on MINIX. Until then, your best bet is to scrounge up stuff that was written for little PDP-11s running V7. Said machines had to contend with much the same problems that PCs running MINIX have to contend with... -- Jim Paradis (paradis@encore.UUCP) 508-460-0500 Devout Secular Humanist and Worshipper of Bacchus in Vintage Years
paula@bcsaic.UUCP (Paul Allen) (09/15/88)
In article <2358@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: >there has been a lot of discussion in the past regarding the huge cost of >source for the minix c compiler. has gcc (the GNU c compiler) and possibly >g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, >this sounds like a very attractive alternative to the existing situation. > >if it has not been ported, can it be ported? gcc is available in a number >of places (i know of UUCP access from osu-cis). gcc has already been ported >to the atari ST (but it has more memory :^). it is BIG and this might be >a problem on 640k systems. Gcc has been ported to run under Unix on 386 boxes. It seems to be fairly stable, but is still generating occaisional bug reports. One hitch is that the 386 gcc currently generates 386 assembly output only. So anyone porting 386 gcc to MINIX will need to come up with a reasonably compatible 386 assembler. From previous discussions, it seems that gcc will *never* run on PC's. So, who wants to volunteer to make MINIX run in protected virtual mode on a 386 and then port gcc? :-) Paul -- ------------------------------------------------------------------------ Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula
hyc@math.lsa.umich.edu (Howard Chu) (09/15/88)
Just for reference, I'm going to be porting gcc to ST Minix, now that I've
got it for TOS. Some kind of networking library would be nice; I'm going to
see how well that latest version of KA9Q adapts to the ST Minix environment
as well. Should be interesting, even if all I have are serial interfaces...
--
/
/_ , ,_. Howard Chu
/ /(_/(__ University of Michigan
/ Computing Center College of LS&A
' Unix Project Information Systemshenry@utzoo.uucp (Henry Spencer) (09/15/88)
In article <2358@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: >... gcc has already been ported >to the atari ST (but it has more memory :^). it is BIG and this might be >a problem on 640k systems. More like "disaster" than "problem". The people who ported it to STs were probably using Mega STs; I'd be surprised if it would fit on a 1040ST with a mere megabyte. Gcc needs **IMMENSE** amounts of memory to compile any substantial program. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cjeffery@arizona.edu (Clinton Jeffery) (09/15/88)
From article <3602@encore.UUCP>, by paradis@encore.UUCP (Jim Paradis): > MAYBE if someone could figure out a way to break the > 64K barrier (we're not even talking the 640K barrier here > yet!) then we can start talking about putting GNU stuff up > on MINIX. If I understand what's been posted about the new 1.3 network software, its interprocess communications facilities will enable Minix to run those large applications which are written well enough to allow a decomposition of the application into component processes. This, however, would involve hand-modifying such programs by someone intimate with their internals. Further, the performance will be bad unless amoeba messages run like greased lightning. I don't know if these criterion will apply to many GNU programs, but it certainly does make Minix on the PC a more imaginable environment for me anyway. Comments anyone? -- | Clint Jeffery, University of Arizona Department of Computer Science | cjeffery@arizona.edu -or- {noao allegra cmcl2}!arizona!cjeffery --
roberto@cwi.nl (Rob ten Kroode) (09/15/88)
In article <4061@louie.udel.EDU> frank@morgan.com (Frank Wortner) writes: # Bill Rosenkranz <rosenkra@alliant.com> writes: # >there has been a lot of discussion in the past regarding the huge cost of # >source for the minix c compiler. has gcc (the GNU c compiler) and possibly # >g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, # >this sounds like a very attractive alternative to the existing situation. # # "Huge" is, in my opinion, an exageration. The source costs $99, not much # more than the $89 that Minix itself costs. Admittedly, I have a steady, # rather well-paying job, so I can fork over a hundred dollars without much # pain. Other people may not be so lucky. Still, in comparison the cost of # many other common bits of software and hardware -- two to three thousand # dollars for a nice PC system comes to mind -- $99 is cheap. "Huge" is defenitely NOT an exageration. The source costs $999. I suppose you don't fork over a thousand dollars without much pain :-) -Rob -- Rob ten Kroode
ceriel@cs.vu.nl (Ceriel Jacobs) (09/15/88)
As long as minix only supports small model, there is no hope of getting GNU c to run, and I suspect this would be difficult, even if minix would support large model. And, the cost of the source for the minix C compiler is'nt "huge" (unless, of course, you think US $100,- is huge). -- Ceriel Jacobs, Vrije Universiteit Amsterdam <ceriel@cs.vu.nl>
rana@hpqtdla.HP.COM (Rana Raychoudhury) (09/15/88)
> rosenkra@Alliant.COM (Bill Rosenkranz) / 5:28 pm Sep 13, 1988 / > > there has been a lot of discussion in the past regarding the huge cost of > source for the minix c compiler. has gcc (the GNU c compiler) and possibly > g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, > this sounds like a very attractive alternative to the existing situation. > > if it has not been ported, can it be ported? gcc is available in a number > of places (i know of UUCP access from osu-cis). gcc has already been ported > to the atari ST (but it has more memory :^). it is BIG and this might be > a problem on 640k systems. > -bill From the GNU CC 'internals' document, page 41 "GNU CC and portability", "The main goal of GNU CC was to make a god, fast compiler for machines in the class that the GNU system aims to run on: 32-bit machines that address 8-bit bytes and have several general registers........" ^^^^^^^^^^^^^^^^^^^^^^^^^ "GNU CC does not contain machine dependent code, but it does contain code that depends on machine parameters such as endianness (whether ths most significant byte has the highest or lowest address of the bytes in a word) and the availability of autoincrement addressing......" ^^^^^^^^^^^^^^^^^^^^^^^^ Now, porting gcc to *minix* may not be a problem per se, but running gcc on machines without certain features (above) will be. From the text above, it would appear that porting gcc to Intel 80X8X architectures MAY be difficult. I would certainly be interested if anybody has done a successful port to (for instance) the Intel 80186/80188. Rana Raychoudhury, Hewlett-Packard QTD. rana@hpqtdla
Leisner.Henr@xerox.com (marty) (09/15/88)
I got GCC running on my Vaxstation. Pretty painless. I tried to get it running on a 32016 (Opus board, Sys V.2). Some problems, I gave up after I invested about 5 hours (for the time being). GCC has a codegenerator for the 80386. When I have time, I'm going to look into seeing what it takes to produce a 386 protected mode minix system. (I already got the 286 running in protected mode). The big problem now is the 64k limit in segment sizes. It should be possible in the 386 to have large programs (like gcc run). My understanding is the ack source code is pretty useless without the ACK system (andy?). I also am getting a 386i soon, so I'll have another 386 system to play on. If you have an arpanet connection, you can gut gnu for free (I think I got mine from simtel20). I think the gnu tools would be a welcome addition to Minix -- I haven't filtered through the source code, but the only think I know of which is missing from Minix would be alloca(). Also the gnu distribution has a plethora of tools. I've had terrible luck with the Minix C compiler (everything I port to it has problems). I quickly recompiled some of my favorite programs on gnu on the Vaxstation (John Gilmore's tar, Ian Darwin's file) and had no problems. BTW -- the gnu vaxstation dhrystones was better than the Ultrix C compilers. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: nsc!nscimg!amps!marty, hplabs!parcvax!leisner
alanf%smile@Sun.COM (Alan Fargusson) (09/16/88)
There are some problems using GCC with products that are sold for profit. Even though MINIX is cheap it is not free, and I don't think that Prentice Hall would be able to distribute the compiler. There may be some way around this, but you may find yourself in court if you are not careful. I think that RMS has already said that he does not want FSF software to be distributed with MINIX. I don't know why. - - - - - - - - - - - - - - - - - - - - - Alan Fargusson Sun Microsystems alanf@sun.com ..!sun!alanf
wnp@dcs.UUCP (Wolf N. Paul) (09/16/88)
In article <68536@sun.uucp> alanf%smile@Sun.COM (Alan Fargusson) writes: > >There are some problems using GCC with products that are sold for profit. Even >though MINIX is cheap it is not free, and I don't think that P-H would >be able to distribute the compiler. There may be some way around this, but you >may find yourself in court if you are not careful. > >I think that RMS has already said that he does not want FSF software to be >distributed with MINIX. I don't know why. The current discussion is about *PORTING* GNU tools to MINIX, not about *DISTRIBUTING* them WITH MINIX. The enduser CAN use GCC with products which are sold for profit, otherwise it would be illegal to use GCC with either UNIX or MS-DOS, since both of these are sold for profit, the one by AT&T, the other by Microsoft. Likewise, all of the computers GNU software runs on are "products sold for profit". RMS does not want FSF software distributed with MINIX because MINIX is a commercial product, being sold for profit. But as I said, that has nothing to do with USING FSF software with MINIX -- you just need to get it from a different source. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
ast@cs.vu.nl (Andy Tanenbaum) (09/16/88)
In article <594@sering.cwi.nl> roberto@cwi.nl (Rob ten Kroode) writes: >"Huge" is defenitely NOT an exageration. The source costs $999. Let me settle this once and for all. There are three distinct items involved here. 1. MINIX C compiler for the PC only: price is about $100 2. Full ACK for a SUN or VAX: university price is about $1000 3. Full ACK with commercial rights: price > $1000, depending on what rights you want. Andy Tanenbaum (ast@cs.vu.nl)
bunda@cs.utexas.edu (John Bunda) (09/16/88)
I have considerable experience with gcc, porting it to an experimental architecture, and I've seen far too much discussion of what I consider to be a moot point. The technical obstacles to getting gcc to run under MINIX are so formidable that the protracted discussion we are reading here is not really worth continuing. The availability of the 386 port of gcc should not be in any way mistaken for a sign that ports to the IBM PC architecture are at all feasible. I don't consider a cross-compiler running on a mainframe or having to buy a 386 class machine to be in the spirit of MINIX or the budgets of most MINIX users. If a new compiler is desirable or necessary, I would look elsewhere before I even attempted to try to shoehorn gcc into a PC. Not that gcc isn't a fine piece of work - it's just that it wasn't designed to fit in the cramped quarters of PC addressability and word size. Sort of like trying to put a V-8 in a Volkswagen. It's not *impossible*, but near enough that it's probably not worth attempting. John Bunda METRIC Project UT Austin bunda@cs.utexas.edu
henry@utzoo.uucp (Henry Spencer) (09/17/88)
In article <7056@megaron.arizona.edu> cjeffery@arizona.edu (Clinton Jeffery) writes: >If I understand what's been posted about the new 1.3 network software, >its interprocess communications facilities will enable Minix >to run those large applications which are written well enough to >allow a decomposition of the application into component processes. Decomposing large applications into component processes is often very difficult; not too many applications naturally fall apart into pieces. Some (e.g. compilers) *appear* to fall apart, but then you discover that the pieces all want access to major data structures. You *can* put those data structures on disk, but the less said about performance impact, the better. (I was peripherally involved, once, with a compiler effort that had to do that. Boy it was slow.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
burgett@steel.COM (Michael Burgett) (09/17/88)
In article <206@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: | |RMS does not want FSF software distributed with MINIX because MINIX is |a commercial product, being sold for profit. But as I said, that has nothing |to do with USING FSF software with MINIX -- you just need to get it from a |different source. | I'm not even sure that rms could stop anyone from distributing gcc with a commercial product.... the "copyleft" states that you must 1) Not sell *gcc* 2) mark your changes as such 3) provide source (or agree to provide source) to gcc to whomever you gave the binary. it seems to me that if PH met the spirit of that agreement then there would be little that the FSF could do. (but then there's a reason that I'm a programmer and not a lawyer. :') ) Mike Burgett adobe!burgett@decwrl.dec.com
vandys@hpindda.HP.COM (Andy Valencia) (09/17/88)
/ hpindda:comp.os.minix / rana@hpqtdla.HP.COM (Rana Raychoudhury) / 5:40 am Sep 15, 1988 / >Now, porting gcc to *minix* may not be a problem per se, but running gcc >on machines without certain features (above) will be. From the text above, >it would appear that porting gcc to Intel 80X8X architectures MAY be difficult. This sounds like the argument against pcc working on 8086s. No general registers, no auto increment/decrement, mov instruction doesn't set the flags, etc. I managed to tweak over the pcc in a couple of days. Wasn't too bad, either. Consider: AX, CX, DX - Perfectly good accumulators. I made them AREGs BX, SI, DI - Perfectly good pointers. BREGs. BP, SP, PC - Reserved. BP keeps the stack frame. DS, ES, CS, SS - Sorry, I did small model. SI and DI could be used as register variables, otherwise they were in the BREG pool. The Sethi-Ullman numbers guided the compiler in either case. It was interesting to watch the compiler adapt to various shortages of registers.... Because the pcc code templates could specify FORCC or not, I just made the obvious move template first, then had one which included FORCC next. The first one matched moves which only needed the effect; the second one matched moves whose result was desired. It was just like the first, but would generate an extra instruction to set the flags after the move. Without memory-memory moves, the data had to be in a register anyway, so it was pretty cheap. If any sites with V7 source would like to track my work, I'll be happy to supply diffs. It isn't easy to get a source license for a lowly PC, but it makes an amusing cross compiler! See the paper "A Tour through the Portable C Compiler" to get a better idea of how this stuff works. Andy
paula@bcsaic.UUCP (Paul Allen) (09/17/88)
In article <68536@sun.uucp> alanf%smile@Sun.COM (Alan Fargusson) writes: >There are some problems using GCC with products that are sold for profit. Even >though MINIX is cheap it is not free, and I don't think that Prentice Hall would >be able to distribute the compiler. There may be some way around this, but you >may find yourself in court if you are not careful. Whoa! It's not quite that bad! There's no problem using GNU software in any way you see fit. You can distribute gcc with a commercial product if you also distribute the gcc sources or otherwise make the sources available. You just can't sell gcc for profit. Also, if you create a derivative work from a GNU product, the derivative work falls under the GNU license and cannot be sold. (At least, that's the way I read it!) If we ever got to the point where a working 386 MINIX existed, PH would certainly be able to find a way to distribute gcc with it! >I think that RMS has already said that he does not want FSF software to be >distributed with MINIX. I don't know why. Stallman has said that gcc (and GNU products in general) will never be ported to brain-dead toy computers like the IBM PC. (I think those were his exact words, too!) GNU software requires relatively large virtual-memory machines. 386-based machines fit the bill quite nicely. So, let's not debate legalities. A 386 MINIX using gcc is possible, and quite desirable from the point of view of a 386 owner. The question of whether PH would want to distribute a 386 MINIX is not related to the question of whether we decide to create such a version. >Alan Fargusson Sun Microsystems >alanf@sun.com ..!sun!alanf -- ------------------------------------------------------------------------ Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula
stuff@crash.cts.com (David Yip) (09/17/88)
In article <594@sering.cwi.nl> roberto@cwi.nl (Rob ten Kroode) writes: >In article <4061@louie.udel.EDU> frank@morgan.com (Frank Wortner) writes: ># Bill Rosenkranz <rosenkra@alliant.com> writes: ># "Huge" is, in my opinion, an exageration. The source costs $99, not much ># more than the $89 that Minix itself costs. Admittedly, I have a steady, ># rather well-paying job, so I can fork over a hundred dollars without much ># pain. Other people may not be so lucky. Still, in comparison the cost of ># many other common bits of software and hardware -- two to three thousand ># dollars for a nice PC system comes to mind -- $99 is cheap. > >"Huge" is defenitely NOT an exageration. The source costs $999. > >I suppose you don't fork over a thousand dollars without much pain :-) > >-Rob >-- >Rob ten Kroode The last time I looked, all GNU software was free to anyone who could ftp to a site that had it. The only costs involved were if someone had to make a tape and send it to you.
frank@morgan.com (Frank Wortner) (09/17/88)
Rob ten Kroode <roberto@cwi.nl> writes ... [concerning my opinion that the price of Minix C source is not "huge ..."] >"Huge" is defenitely NOT an exageration. The source costs $999. > >I suppose you don't fork over a thousand dollars without much pain :-) > >-Rob >-- >Rob ten Kroode $999 is news to me. My checkbook says I bought the compiler from UniPress Software for *$99*, not $999. That means I paid a hundred dollars, not a thousand. Either that, or my next stop will be in bankruptcy court. ;-) Frank P.S. I do fork over a thousand dollars with a fair amount of pain --- try pricing rental apartments in and around New York City. :-(
paula@bcsaic.UUCP (Paul Allen) (09/20/88)
In article <1398@ceriel.cs.vu.nl> ceriel@cs.vu.nl (Ceriel Jacobs) writes: >As long as minix only supports small model, there is no hope of getting >GNU c to run, and I suspect this would be difficult, even if minix would >support large model. Yes, but small model on a 386 means 4Gb segments! Substantial changes will be needed to make a 386-based minix that can support gcc. There are several 286 protected-mode minix's floating around. Rather than 'no hope', I would say there's considerable hope that we can make gcc run under minix. Assuming that a 386 minix with segments >64K exists, the next big challenge will be the fact that the current 386 gcc implementation is based on System V. Deity only knows how many library routines will have to be re-invented and added to minix! Paul -- ------------------------------------------------------------------------ Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula
paula@bcsaic.UUCP (Paul Allen) (09/20/88)
In article <3342@cs.utexas.edu> bunda@cs.utexas.edu (John Bunda) writes: >I have considerable experience with gcc, porting it to an experimental >architecture, and I've seen far too much discussion of what I consider Aha! A gcc wizard! Great! >to be a moot point. The technical obstacles to getting gcc to run >under MINIX are so formidable that the protracted discussion we are >reading here is not really worth continuing. >The availability of the 386 port of gcc should not be in any way mistaken >for a sign that ports to the IBM PC architecture are at all feasible. I don't Nobody is suggesting that a port of gcc to the IBM PC is feasible. What I want to see is a port of minix to the 386. Then the problem reduces to porting gcc to V7. Based on your gcc experience, is that feasible? >consider a cross-compiler running on a mainframe or having to buy a 386 >class machine to be in the spirit of MINIX or the budgets of most MINIX >users. If a new compiler is desirable or necessary, I would look elsewhere Well, yes. Requiring a 386-class machine is outside the original intent of MINIX. Should that stop those of us who *have* such machines from trying to build a version of MINIX to take full advantage of our machines? I think not, and I'd like to move forward. >before I even attempted to try to shoehorn gcc into a PC. Not that gcc >isn't a fine piece of work - it's just that it wasn't designed to fit >in the cramped quarters of PC addressability and word size. Sort of >like trying to put a V-8 in a Volkswagen. It's not *impossible*, but >near enough that it's probably not worth attempting. Hey, I've *seen* Volkswagens with V-8's! Shoehorning gcc into a PC would be harder than that! Let's talk about shoehorning it into a 386-based MINIX. Paul -- ------------------------------------------------------------------------ Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula
rosenkra@Alliant.COM (Bill Rosenkranz) (09/22/88)
In article <4061@louie.udel.EDU> frank@morgan.com (Frank Wortner) writes: ->Bill Rosenkranz <rosenkra@alliant.com> writes: ->>there has been a lot of discussion in the past regarding the huge cost of ->>source for the minix c compiler. has gcc (the GNU c compiler) and possibly ->>g++ (the GNU c++ compiler) been ported to minix? since it is essentially free, ->>this sounds like a very attractive alternative to the existing situation. -> ->"Huge" is, in my opinion, an exageration. The source costs $99, not much ->more than the $89 that Minix itself costs. Admittedly, I have a steady, ->rather well-paying job, so I can fork over a hundred dollars without much ->pain. Other people may not be so lucky. Still, in comparison the cost of ->many other common bits of software and hardware -- two to three thousand ->dollars for a nice PC system comes to mind -- $99 is cheap. wait a second, partner...if i recall correctly, the stuff u get for $99 is NOT the back end stuff which (correct me if i'm wrong) is something like $800 or so...NOT cheap, even for me (i have 3 computers on my desk at home and plan to buy a mac II). ->I also don't believe that GCC is "essentially free." There are a few hidden ->costs involved. First is media. If I want GCC, I will have to supply i got gcc for my 4 MB atari (:^) for the cost of 5 disks (which i got back and which serve as a backup...as i said: essentially FREE... (i got g++ via uucp as well). i'm sorry, it DID cost me 2 way postage, about $3... u can get it via uucp (~2-3 MB) for < $50 at 2400 baud (late nite, weekends) ->Even if all of these costs are reduced to zero, there is still the possibility ->make that the probability, that GCC won't fit into the 64K per program ->limitation of "stock" IBM PC Minix. (Wow, ten years ago we all thought ->64K was more memory than anyone would ever need!) GCC and GNU were not ->meant for "small" computers. This does not rule out cross compilers, ->but that's a frustrating and expensive way to play. i agree here...actually gcc will be VERY difficult to port to segmented memory machines (after all, "segments are for worms" as one of the people who responded to my original question replied :^). ->Don't get me wrong. I'm not knocking GCC. Although I have no personal ->experience with it (yet), I'd be willing to bet that it's a good piece of ->work. It probably produces better code than the Minix ACK C compiler. ->The source is probably more useful. Minix C source does not include the ->tools used to generate tables for the table-driven front and back ends of ->the compiler, while a complete GCC distribution probably includes everything. gcc is very nice on the ST, especially with a 2 MB ramdisk and another 2 MB left over. guess i'll just wait for ST Minix... -> For me, ->the ability to "plug in and play" was worth the cost. not for me, however. i need to fiddle around :^) -> Frank -bill
bunda@cs.utexas.edu (John Bunda) (09/22/88)
> I want to see is a port of minix to the 386. Then the problem reduces > to porting gcc to V7. Based on your gcc experience, is that feasible? the 386i port is probably pretty close already. However, function linkage code and assembler syntax would probably need some work, and that reminds me, how about a 386 assembler for minix, and ld, though the library is actually in pretty good shape (guessing here). Don't get me wrong, it's certainly *possible*. But you're assuming an awful lot; if you're going to do a real 386 MINIX anyway, the gcc port would probably be a few weeks work. But, to stretch my stupid analogy, what you seem to be asking is: "Assuming I've beefed up the transaxle, installed heavier brakes and suspension components, designed and fabricated engine mounts, reinforcing hardware, etc., and I'm not too particular about the noise and the way the interior looks, can I drop this v8 into my volkswagen?" sure, should bolt right up! why didn't wolfsburg think of it? ;-) -john -- ................................... John Bunda UT CS Dept. bunda@cs.utexas.edu Austin, Texas
cudcv@warwick.ac.uk (Rob McMahon) (09/27/88)
In article <1720001@hpqtdla.HP.COM> rana@hpqtdla.HP.COM (Rana Raychoudhury) writes: > "The main goal of GNU CC was to make a god, fast compiler for machines in > the class that the GNU system aims to run on: 32-bit machines that address > 8-bit bytes and have several general registers........" > ^^^^^^^^^^^^^^^^^^^^^^^^^ Whilst GCC would like to use several registers, and much of its optimization effort goes into allocating registers well, this doesn't mean it wouldn't work on a machine with fewer registers. > "GNU CC does not contain machine dependent code, but it does contain code > that depends on machine parameters such as endianness (whether ths most > significant byte has the highest or lowest address of the bytes in a word) > and the availability of autoincrement addressing......" > ^^^^^^^^^^^^^^^^^^^^^^^^ The code that depends on such features is all #ifdef'ed, it doesn't *require* such features, it just uses them if they're available. There are certainly machines without auto-increment that run GCC (I'm on one now), and it runs on machines of both types of endianness. > Now, porting gcc to *minix* may not be a problem per se, but running gcc on > machines without certain features (above) will be. From the text above, it > would appear that porting gcc to Intel 80X8X architectures MAY be > difficult. The problems you cite are not the real problems, I should think the problem is going to be: cudcv (53) %> size /usr/local/lib/gnu/gcc/cc1 text data bss dec hex 417792 40960 21744 480496 754f0 Sun-3 581632 16384 18752 616768 96940 SPARC 655360 49152 13920 718432 af660 Gould cudcv (54) %> (cc1 is the compiler pass, this is on a Sun-3) Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England