kisworo@cutmcvax.cs.curtin.edu.au (Marsudi Kisworo) (12/11/90)
I am developing a robotic/vision application using Amiga as the robot controller. Currently I am using Lattice C v5 to develop the application. Due to difficulties in representing the knowledge, I am looking to use Lattice C++ object-oriented facility. But before I buy the LC++, I want to know whether it compiles ordinary LC source since I have written a lot of routines in C. Is there anybody in the netland who know this and have experience with this ? Also is there any problem arises when porting Lattice C code to Lattice C++ code ? Will LC++ generates C code like Unix C++ ? (I am familiar with Unix C and C++). Thanks for any info. Marsudi Kisworo Comp. Sci, Curtin Uni, Western Australia
pete@violet.berkeley.edu (Pete Goodeve) (12/13/90)
In <kisworo.660924569@cutmcvax.cs.curtin.edu.au> (11 Dec), Marsudi Kisworo (kisworo@cutmcvax.cs.curtin.edu.au) writes: > [....] before I buy the LC++, I want to know whether > it compiles ordinary LC source since I have written a lot > of routines in C. Is there anybody in the netland who > know this and have experience with this ? Also is there > any problem arises when porting Lattice C code to > Lattice C++ code ? Will LC++ generates C code like Unix C++ ? I've had Lattice C++ for about three years, and it has mostly worked fine for me. (I actually used it to cross-develop a (large) project that was finally compiled under Zortech on that machine we don't mention. Virtually all of the few minor problems I had were due to (early) Zortech's deficiencies, except for one place -- don't remember the circumstances I'm afraid -- where the Lattice Cfront section generated bad C code!) Lattice C++ IS basically a precompiler (Cfront) for their standard C compiler. It came with version 4 of that; I'm using 5.04 with no problems. (I have 5.1 but haven't checked it with that yet.) I don't see any problem with importing standard C routines, except for the few intolerances that C++ has (noted in Stroustrup I think); I'm not sure whether C++ accepts old style parameter declarations or not -- I think it does, with a warning. I always use the new convention these days. I have on a few occasions simply dropped in some plain C from somewhere else, without troubles. Cfront does of course generate plain C source, but this calls functions from the C++ library (in addition to lc.lib) to do most of the special tricks, so you can't easily drop thus source back into a plain C program. It's perfectly all right to link in plain C object modules with C++, though. My real worry about purchasing it at this stage would be its current status. Lattice never really did any updating, and now that SAS has taken over C development, I have no idea what their plans are. What about it, SAS? -- Pete --
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (12/16/90)
In article <1990Dec12.175455.13985@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >My real worry about purchasing it at this stage would be its current >status. Lattice never really did any updating, and now that SAS has >taken over C development, I have no idea what their plans are. What >about it, SAS? SAS has said, on BIX, that they are working on an SAS C++ compiler. This will be a C++ to 68000 code compiler, not a C++ to C translator like the current Lattice product. No word yet on release date, or upgrade policies. I don't need a C++ compiler *right* *now*, so I'm going to wait. disclaimer: I just read about it, so that's all I know. -Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
dailey@frith.uucp (Chris Dailey) (12/17/90)
In article <1990Dec15.192957.13441@batcomputer.tn.cornell.edu> riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes: >SAS has said, on BIX, that they are working on an SAS C++ compiler. >This will be a C++ to 68000 code compiler, not a C++ to C translator >like the current Lattice product. No word yet on release date, or >upgrade policies. I don't need a C++ compiler *right* *now*, so I'm >going to wait. I've heard it may be ready by Fall '90, but there are many factors that could easily make that sooner or later. I should be getting a 3000 (or maybe a 3500 or 4000 by then??? :) around then and this is one of my planned purchases. >disclaimer: I just read about it, so that's all I know. My disclaimer: everything I said above is subject to change. Especially the bit about me getting a 3000 if my fiance-then-wife changes her mind. ;) >-Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) >-Wilson Lab, Cornell University -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; DDR = NULL; num_countries --;
abair@turbinia.sps.mot.com (Alan Bair) (12/18/90)
In article <1990Dec15.192957.13441@batcomputer.tn.cornell.edu> riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes:
SAS has said, on BIX, that they are working on an SAS C++ compiler.
This will be a C++ to 68000 code compiler, not a C++ to C translator
like the current Lattice product. No word yet on release date, or
upgrade policies. I don't need a C++ compiler *right* *now*, so I'm
going to wait.
disclaimer: I just read about it, so that's all I know.
Gee, this sounds an awful lot like the FSF g++ compiler. Hopefully the
SAS one will be based on C++ 2.0. Considering that an initial port
of gcc has been announced on the net, is anyone working on using that
to port g++? Once gcc is working on the Amiga, it should not be too
hard to port g++, since it is just patches to gcc. However, I don't
know how it works, but the extra runtime linking for C++ could present
some problems. Just wondering.
--
Alan Bair SSDT (formerly SPS CAD)
Motorola, Inc. Logic Simulation & Test
Austin, Texas abair@turbinia.sps.mot.comdcl@ncsc1.ATT.COM (Dave Love) (12/19/90)
In article <ABAIR.90Dec17154736@turbinia.sps.mot.com> abair@turbinia.sps.mot.com (Alan Bair) writes: >Gee, this sounds an awful lot like the FSF g++ compiler. Hopefully the >SAS one will be based on C++ 2.0. Considering that an initial port ^^^ (shouldn't that be 2.1?) >of gcc has been announced on the net, is anyone working on using that >to port g++? Once gcc is working on the Amiga, it should not be too >hard to port g++, since it is just patches to gcc. However, I don't I haven't seen the Amiga version of gcc yet; hopefully someone who has can answer a quick question. On UNIX boxes, gcc slurps the entire input file onto the stack and processes it from there. How was this handled on the Amiga version? >-- >Alan Bair SSDT (formerly SPS CAD) >Motorola, Inc. Logic Simulation & Test >Austin, Texas abair@turbinia.sps.mot.com -- Dave Love UUCP: dcl@ncsc1.att.com CI$: 75126,2223 bix: dlove -- "MS-DOS... The ultimate PC virus." --
jep@mtiame.mtia.oz (Jesper Peterson) (12/21/90)
In article <716@ncsc1.ATT.COM> dcl@ncsc1.ATT.COM (Dave Love) writes: >I haven't seen the Amiga version of gcc yet; hopefully someone who has >can answer a quick question. On UNIX boxes, gcc slurps the entire >input file onto the stack and processes it from there. How was this >handled on the Amiga version? The same. Recommended stack is 100000 or 200000 to be safe. It eats heap as well, I have 1M chip + 2M fast and trying to port Gnu Smalltalk I ran out of memory trying to compile the interpreter module (~100k source file) with optimisation turned on. I squeezed it in by running gcc by hand (ie. not from make) with t: on hard disk instead of ram disk. I am pleased to note that gcc handles the out of memory condition cleanly. I'd bee really interested in seeing g++ as well I might add. I'll be looking for an 8M RAM board RSN I think. Jesper. -- ------------------------------------------------------------------------------ USEnet: jep@mtiame.mtia.oz.au UUCP: ...!uunet!munnari!mtiame.oz!jep [...] I had to leave out reality to keep the post clean and to the point. - jeremy@milton.u.washington.edu (Jeremy York) in rec.music.misc