mark@intek01.UUCP (Mark McWiggins) (07/26/88)
We're about to adopt C++ as our standard language, and probably get the AT&T source, since we target several environments. Has anyone ported the translator to the Mac? I know it's a big program and thus would probably choke MPW or Lightspeed because of their 32K global data limit. But it seems to me that a port through Aztec C should be relatively easy, since it (reportedly) does not share the 32K restriction. Am I hopelessly naive, or have you done this already? Thanks in advance for any insight. -- Mark McWiggins UUCP: uunet!intek01!mark DISCLAIMER: I could be wrong. INTERNET: intek01!mark@uunet.uu.net (206) 455-9935
jwhitnell@cup.portal.com (07/28/88)
>We're about to adopt C++ as our standard language, and probably get the >AT&T source, since we target several environments. >... >Am I hopelessly naive, or have you done this already? Thanks in advance >for any insight. Yeah. A little company called Apple is working on this for MPW. A Beta version is due about 6 weeks after MacWorld. If you're a certified developer (and if you're not you should be), you might give your favorite evangilist a call and see about being an alpha site. -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell
ech@poseidon.UUCP (Edward C Horvath) (07/29/88)
> We're about to adopt C++ as our standard language, and probably get the > AT&T source, since we target several environments. Has anyone ported > the translator to the Mac? I know it's a big program and thus would > probably choke MPW or Lightspeed because of their 32K global data limit. > But it seems to me that a port through Aztec C should be relatively easy, > since it (reportedly) does not share the 32K restriction. I haven't seen the latest AT&T version; the last attempt I heard of ('twas not I) to attempt the port to Aztec bounced up against a 32-character limit on extern variable names. I don't know of any plans to up that limit. =Ned=
drc@claris.UUCP (Dennis Cohen) (07/29/88)
You might want to wait a month or two as MPW 3.0 is coming out from Apple and C++ is available for it. It will also fit right in with MacApp so MacApp people will no longer be constrained to Pascal (and some assembly). Though I haven't used it yet, the announcement info was that it was an implementation of the AT&T C++ to fit in with the new MPW C compiler. Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
kennel@minnie.cognet.ucla.edu (Matthew Kennel) (07/30/88)
In article <461@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: >> We're about to adopt C++ as our standard language, and probably get the >> AT&T source, since we target several environments. Has anyone ported >> the translator to the Mac? > >I haven't seen the latest AT&T version; the last attempt I heard of ('twas >not I) to attempt the port to Aztec bounced up against a 32-character >limit on extern variable names. I don't know of any plans to up that limit. > >=Ned= I seem to remember that there was posted somewhere (probably comp.sources.unix) a program that translates very_long_variable_names into something more CRYPTC. You might want to put this filter in between the c++ and the compiler. I'm not sure, but you might be able to get it via anon. FTP at uunet.uu.net. Matt K kennel@cognet.ucla.edu
fst@mcgp1.UUCP (Skip Tavakkolian) (07/30/88)
In article <325@intek01.UUCP>, mark@intek01.UUCP (Mark McWiggins) writes: > We're about to adopt C++ as our standard language, and probably get the > AT&T source, since we target several environments. Has anyone ported > the translator to the Mac? I know it's a big program and thus would > probably choke MPW or Lightspeed because of their 32K global data limit. [ deleted ] > -- > Mark McWiggins UUCP: uunet!intek01!mark The problem, as I understand it, is to find a C compiler and assembler that would be able to digest the output of the C++ (at&t's cfront). It generates some very long names that are required to be distinguishable beyond 30 or so chars even by the assembler. Sincerely -- Fariborz ``Skip'' Tavakkolian UUCP ...!uw-beaver!tikal!mcgp1!fst UNIX is a registered trademark of AT&T
beard@ux1.lbl.gov (Patrick C Beard) (07/31/88)
In article <1479@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: >In article <325@intek01.UUCP>, mark@intek01.UUCP (Mark McWiggins) writes: >> We're about to adopt C++ as our standard language, and probably get the >> AT&T source, since we target several environments. Has anyone ported >> the translator to the Mac? I know it's a big program and thus would >> probably choke MPW or Lightspeed because of their 32K global data limit. Whether or not it would choke either LSC or MPW is whether the person who ports it to the respective language could understand the program well enough to replace the global data with data dynamically allocated on the heap. >> -- >> Mark McWiggins UUCP: uunet!intek01!mark > >The problem, as I understand it, is to find a C compiler and assembler that >would be able to digest the output of the C++ (at&t's cfront). It generates >some very long names that are required to be distinguishable beyond 30 or so >chars even by the assembler. > LSC can accept variable names that are very long, I think basically of unlimited length. It can generate inline assembly code for those tight spots. It has a source level debugger. MPW C can do none of these right now. If I was given the job to port cfront. I would do it in LSC. >-- >Fariborz ``Skip'' Tavakkolian >UUCP ...!uw-beaver!tikal!mcgp1!fst > +=============================================================+ | Patrick C. Beard | | Lawrence Berkeley Laboratory | | Automated Supernova Search | +-------------------------------------------------------------+ | PCBeard@LBL.gov (arpa only) | +=============================================================+
dan@Apple.COM (Dan Allen) (08/07/88)
In article <461@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: >> We're about to adopt C++ as our standard language, and probably get the >> AT&T source, since we target several environments. Has anyone ported >> the translator to the Mac? I know it's a big program and thus would >> probably choke MPW or Lightspeed because of their 32K global data limit. >> But it seems to me that a port through Aztec C should be relatively easy, >> since it (reportedly) does not share the 32K restriction. Apple Computer is officially porting CFront, the AT&T translator, to be an MPW Tool. It is part of MPW 3.0, which is currently undergoing the first Beta release even as we speak. MPW C++ is a port of of some version of CFront (post 1.0) that supports multiple inheritance. As it it breaking the global data limit, Apple has solved the problem in the same way that I have been telling people to on comp.sys.mac.programmers: to use resources for the large initialized data arrays that come along with the use of yacc and lex. Dan Allen Software Explorer Apple Computer throngs of its first Beta release even as we speak.
dan@Apple.COM (Dan Allen) (08/07/88)
In article <1479@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes: >In article <325@intek01.UUCP>, mark@intek01.UUCP (Mark McWiggins) writes: >> We're about to adopt C++ as our standard language, and probably get the >> AT&T source, since we target several environments. Has anyone ported >> the translator to the Mac? I know it's a big program and thus would >> probably choke MPW or Lightspeed because of their 32K global data limit. >[ deleted ] >> -- >> Mark McWiggins UUCP: uunet!intek01!mark > >The problem, as I understand it, is to find a C compiler and assembler that >would be able to digest the output of the C++ (at&t's cfront). It generates >some very long names that are required to be distinguishable beyond 30 or so >chars even by the assembler. Although this is a problem for many assemblers, it does NOT happen to be the MPW assembler problem. All of the MPW language translators (C, Pascal, Assembly) can deal with at least 64 character names without any problem. The 32K global limit is an architectural limitation of the Motorola 68000 (not 68020, however) and the way it interacts with the conventions set up for the Macintosh OS. (Address register addressing is limited to a 16-bit offset for the 68000, and that is how global data is addressed in the Mac OS; it is a signed offset, so you have 32K of register A5 relative space.) This is not a real limitation, however, because using the heap and dynamic calls like malloc, you can address up to available RAM (8 MB for Mac II running Mac OS). Dan Allen Software Explorer Apple Computer
dan@Apple.COM (Dan Allen) (08/07/88)
In article <561@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >LSC can accept variable names that are very long, I think basically of >unlimited length. It can generate inline assembly code for those tight >spots. It has a source level debugger. MPW C can do none of these >right now. If I was given the job to port cfront. I would do it in LSC. Cfront has been ported via MPW C for almost a year now. MPW 3.0 will feature a source level debugger. MPW C does not need to generate inline assembly code because MPW includes a top-notch assembler as a standard tool. It assembles at over 40,000 lines/minute. And MPW C can handle very long identifiers as well. Apple's MPW C++ in in Beta test currently and will be available Real Soon Now. Dan Allen Software Explorer Apple Computer
shane@chianti.cc.umich.edu (Shane Looker) (08/09/88)
In article <15236@apple.Apple.COM> dan@apple.apple.com.UUCP (Dan Allen) writes: > >Cfront has been ported via MPW C for almost a year now. MPW 3.0 will >feature a source level debugger. MPW C does not need to generate inline ^^^^^^^^^^^^^^^^^^^^ From the Marquis de Sade school of programming? :-) >assembly code because MPW includes a top-notch assembler as a standard >tool. Actually, I was told that the Assembler was going to be unbundled from the shell, so you would have to buy the MPW Shell, C compiler, and Assembler to use the "standard" tool. Besides, I always find it to be a major pain to write an entire routine (including entry/exit) to impliment 4 lines of assembly code. > It assembles at over 40,000 lines/minute. And MPW C can handle ^^^^^^^^^^^^^^^^^^^ Advertising hype. This assumes source code on RAM disk, as well as all #include files, and probably the C compiler as well. (Sorry, but these numbers are a real sore point with me.) What about linking time? >Dan Allen I didn't intend this to be a real flame, but my experience with MPW makes me think that it is a dog. The code generated is nice, but the compilers are slow, the linkers are slow, and you need a meg to run under MultiFinder. The source code debugger will take probably at least 3Meg (from rumors only, this isn't gospel). Right now the minimum MPW installation probably takes 3 Megs for the shell and tools and C compiler. It isn't going to get any smaller. Your mileage may vary. All warrenties, explicit and implicit are null and void. Shane Looker Looker@um.cc.umich.edu
dan@Apple.COM (Dan Allen) (08/15/88)
I agree the MPW is large and slow in its C compiler area, but the assembler IS fast: without any RAM disks (but on a Mac II), and with extensive macro processing, I just assembled at 32000 lines/minute the sources to MacsBug, WHILE under MultiFinder. If this discussion is to continue, let's move it to the comp.sys.mac.programmer group... Dan Allen Apple Computer