ospwd@emory.UUCP (Peter Day {EUCC}) (05/27/87)
Below is the original posting, followed by a summary of the replies.
Extracts of the original posting that were included in the replies have
been removed. I want to thank all who responded: The responses were
very helpful.
The responses indicate that there are three main choices: Aztec C,
Lightspeed C, and Macintosh Programmer's Workbench (MPW).
I ordered Lightspeed C because it represents a low cost way to get
experience with Macintosh development in C, and a lot of people like
it, so it can't be too bad.
***** ORIGINAL POSTING *****
Subject: Best C dev env for Mac?
What is the best C program development environment for the
Macintosh? (Make up your own definition of "best".)
Which is better, Aztec C or Lightspeed C?
Please send responses directly to me and I will summarize to the
Net if appropriate.
Thanks,
Peter Day
CSNET: ospwd@emoryu1
ARPA: ospwd@emoryu1.arpa
UUCP: { akgua, gatech }!emoryu1!ospwd
BITNET: ospwd@emuvm1, ospwd@emoryu1
USPS: Computing Center, Emory University, Atlanta, GA 30322
PHONE: 404/727-7678
**********
In-Reply-To: <2039@emory.UUCP>
From gatech!seismo!mit-eddie!zrm Mon Apr 27 20:04:32 1987
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
As you seem to have concluded, Aztec C and LightspeedC are two of the
best environments for Macintosh programming. I chose them for my book
"C Programming Techniques for the Macintosh" because they are closest
to the Pascal standard for the Macintosh in that they have 16 bit
ints, 32 bit pointers, etc. They also have excellent Toolbox
interfaces, including all the "Pascal only" traps. An additional nice
feature both these compilers share is the "pascal" storage class,
which enables the C programmer to write C routines that use Pascal
calling conventions -- useful for filter procs.
Of these two, and the half dozen others I reviewed in preparing my
book, I continue to use LightspeedC. I prefer LightspeedC because it
links and compiles so incredibly fast.
I would stay away from compilers with different size data types as
Pascal, with Toolbox interfaces that do "clever" things like
converting null-terminated strings into Pascal strings (or any other
automatic conversion between your program and the Toolbox), or
compilers that seem to have fallen of the edge of the Earth, (anyone
remember Hippo C?)
Good luck.
-Zigurd
From sunatl!sun!gnome.cs.cmu.edu!hugo Tue Apr 28 00:31:17 1987
LightSpeedC is the fastest, friendliest, easiest C development environment I
have ever seen. If you need to generate a lot of code, in C, very easily,
then nothing beats it. It's great for prototyping, utilities, DAs,
practically anyting.
The tradeoff is, that you're stuck with what they have given you. The
environment is not extensible, so nifty's like yacc, lex, awk, C++ and all
those other Unixish utilities are impossibleto use easily.
So, if you really need flexibility, and can give up some speed (Mac II's are
fast :-), then don't get LightSpeed. But, don't get Aztec either, because
for that price, you may as well get MPW, which is better, and hasa great C
compiler to boot.
But, if you are hacking on a small to medium large scale, and don't really
need any tools but a fast compiler and smart editor, nothing, *nothing*
beats LSC.
That's what I think.
Pete
--
ARPA: hugo@cmu-cs-gandalf.arpa BELL:412-681-7431
UUCP: ...!{ucbvax,ihnp4,cmucspt}!hugo@cmu-cs-gandalf.arpa
USPS: 5170 Beeler St., Pittsburgh PA 15213
From akgua!seismo!rochester!ur-tut!dagl Tue Apr 28 05:02:35 1987
:
I find both to be useful, depending on the type of work I am doing.
When I am doing something which primaraily involves the Mac interface,
I do my work in LSC. But when I am using libraries I've grown accustomed
to on UNIX machines (e.g. stdio) I rely on Aztec C, because it seems to
handle them better. I tend to do the development of internal (and hopefully,
portable) routines in Aztec C; I've been working on a mathematical function
interpreter and some numerical analysis stuff as well. It's just faster
to write a simple stdio interface to test a new routine in Aztec C.
But then I port it all to LSC and write the *real* interface code there.
---------------------------------------------------------------------------
David Glowny | dagl@tut.cc.rochester.edu (or) ...!rochester!ur-tut!dagl
| US-Mail: PO Box 30996 - Rochester, NY 14627
---------------------------------------------------------------------------
From gatech!seismo!harvard!endor!stew Tue Apr 28 06:49:50 1987
Organization: Aiken Computation Lab Harvard, Cambridge, MA
:
LightSpeed is a great development and prototyping environment,
but I wouldn't use it for programs to sell -- the runtime
library has problems which guarentee that any application
written with LightSpeed C will fail on future macintoshes.
For my work, I use LightSpeed for development and MPW C for
producing the final application. If you're careful (and use
the Pascal glue so that strings aren't converted between
null-terminated and count-byte forms) you can compile the same
source with either compiler.
Stew Rubenstein
seismo!harvard!rubenstein
From sunatl!sun!seismo!scubed!sdcsvax!jww Tue Apr 28 09:38:52 1987
There's a review of C compilers forthcoming for Byte, written by
a famous Macintosh expert.
It concludes that LSC is the fastest. If you like the Aztec environment,
though, you'll probably like MPW (not reviewed) better, since it's more
complete.
From gatech!seismo!andrew.cmu.edu!rs4u# Tue Apr 28 10:07:19 1987
Absolutely Lightspeed C.
Best == Good, fast, mac-Like editor (with arrow-key support), unlimited
text capacity (all in RAM), incredibly fast compiler, ditto linker (
linkage consists of simply verifying all module references),
"
"project" file structure which makes segmentation and source management
simple ("make" is completely automated, so you don't have to worry --
all dependent files are recompiled), and good debugger support
TMON and Jasik's DEBUGGER both have support for LSC.
Also, good code generation (at least as good as Aztec).
MUCH better price than Aztec ($175 list vs. $395 list).
--Rich
Richard M. Siegel
Materials Characterization Instrumentation Section
Mail Stop 231
NASA/Langley Research Center
Hampton, Virginia 23665
(804) 865-3036
Arpanet: rs4u@andrew.cmu.edu
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u
From gatech!seismo!cmcl2!nyu-acf2.arpa!siritzky Tue Apr 28 11:44:13 1987
I have had a lot of problems with all the versions of C on the Mac!
MY situation is that I have a large amount of C code that has been
ported from Unix 4.2 to Unix 4.3 on a VAX, to VAX VMS C, to C on the
IBM PC/AT, and to at least 5 other machines. Each of these ports was
done with little bother - i.e. one man month or less. When I tried
to port to the Mac I first went with Consulair C. It is rubbish! It
is not even C. They have arbitrarily changed some of the scoping rules
of C. Then I tried Aztec C. It could not cope with some of the code. It
kept crashing. Lightspeed C was better, but it also choked on a few of
the functions. Then we hit another problem. All of these C compilers
will only allow you a 32K code segment - for the whole program. In our
case this was way too little.
I have since tried the MPW C. It is better than the others for my problems,
although it still has the 32k limitation (I'm told that this is a problem
with the Mac OS!). I do know that the CWI people in Amsterdam wanted to
put an implementation of ABC on the Mac (ABC is a GREAT language) and
they said that the only C compiler that could do it was the MPW C!
Now, all this may not apply to you. If you are starting from scratch,
with no existing code that has to be ported, then you may be able to work
within the confines of one of the compilers. In that case I recommend either
the Lightspeed or the MPW.
==================================================================
Brian Siritzky, C.I.M.S., 251 Mercer Street, New York, NY 10012
ARPA : siritzky@nyu
uucp : ...!cmcl2!acf2!siritzky
^
|________This is a small 'L', not a one
==================================================================
From akgua!seismo!mnetor!unicus!Reid.A.Ellis Wed Apr 29 00:18:57 1987
I would have to say, and I think many will agree, that Lightspeed C cannot
be beaten for small programs which are on the same order of size as binhex,
unpit, and such (around 40-60k). But for Really Big Projects (we're talking
Microsoft Excel or Drak Castle sized here) you have to go with MPW C. It
produces the best code of any C compiler around, and has all the development
tools you need, except for maybe lint.
Some people claim the best thing to do is to prototype things in Lightspeed
C and then develop them in MPW. You can do this if you keep away from the
incompatabilities between these two compilers (strings passed to toolbox
routines being the prime problem).
The bottom line:
Lightspeed C for fast tool development and prototyping
MPW C for massive projects
Let me know what else you get,
Reid.
--
Reid Ellis, aka Clith de T'nir
{seismo!mnetor, utzoo!yetti}!unicus!reid.ellis (dumb uucp)
mnetor!unicus!reid.ellis@seismo.css.gov (dumb arpa)
From akgua!ihnp4!gargoyle!sphinx!fdot Wed Apr 29 01:19:57 1987
Organization: U Chicago Computation Center
I use Lightspeed C -- it's a good environment for developing "real Mac"
programs, and it's very un-buggy, which was a relief after using MegaMax C
for a year. It also has function prototyping, which is the next best
thing to lint, which I haven't seen on the Mac.
I haven't looked too hard at Aztec C, but my feeling is that it doesn't
measure up. However, it was a very narrow choice between Lightspeed
and MPW C, which is a really strong compiler set in a *very* powerful
environment. I finally chose Lightspeed for the turn-around time.
--Tom Lippincott
..ihnp4!gargoyle!sphinx!fdot
From gatech!akgua!ihnp4!amd!roy Wed Apr 29 02:34:58 1987
:
For C, I think Lightspeed C has it hands down over all of the others,
and over Aztec C without a doubt!
For Pascal, it's between Lightspeed Pascal and MPW.
Roy Carlson
Software Consultant
From gatech!tektronix!tekig4.TEK.COM!bradn Wed Apr 29 02:35:52 1987
Organization: Tektronix, Inc., Beaverton, OR.
:
Unfortunately, I only have experience with Aztec C -- I've never tried
lightspeed C.
I like Aztec C a lot.
One of the reasons is the unix-like interface (as opposed to a Mac-like
interface). I use Unix at work, and I appreciate being able to use
similar tools when programming on the Mac. Aztec C includes programs
that are very close to Unix' "make" and "vi".
Another thing I like about Aztec C is that I have written complex
applications involving custom controls and track routines without ever
having to resort to assembly language or strange "glue" routines --
Aztec C provides routines to interface to all of the toolbox calls. I
like Aztec's treatment of pascal vs C format of strings -- it doesn't
automatically convert strings for you, but it provides subroutines to
explicitly do the conversion.
I have seen very few complaints about Aztec C on the net. At the same time
a lot of folks have sent in complaints about various Lightspeed C bugs or
features.
Good luck with your choice,
Brad Needham
bradn@tekig4.TEK.COM
From akgua!seismo!mcvax!uva!maarten Wed Apr 29 06:32:34 1987
Organisation: Facultaire Vakgroep Informatica, Universiteit van Amsterdam
Kruislaan 409, 1098 SJ Amsterdam, The Netherlands
Phone: +31 20 5925022
Telex: 10262 hef nl
Organization: FVI, University of Amsterdam
To my opinion, if you can afford the hardware :-), the best C
is MPW C (get it through APDA, about $100-200)
--maarten
In real life: Maarten Carels
Computer Science Department
University of Amsterdam
email: maarten@uva
{philabs, decvax, seismo}!mcvax!uva!maarten
Date: Tue, 28 Apr 87 17:22:07 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
I've been using Manx Aztec C for program development on the
Macintosh for over two years, and have been very satisifed with
it. I can't say that I've compared it to any other versions of
C for the Mac. I've been happy enough with Aztec C that I've had
little incentive to do that. I'd be happy to answer any questions
you have about Aztec C, run benchmarks, etc. I do my development
work on a Mac Plus with two 800K floppy disk drives.
Peter
From gatech!tektronix!tekig4.TEK.COM!larryha Thu Apr 30 00:46:20 1987
Organization: Tektronix, Inc., Beaverton, OR.
I've used both, and Lightspeed C is miles ahead of Aztec C.
If you prefer a SHELL based environmentlike UNIX, then Aztec
gives you that in a prettygood package. But if you like MAC
type environments, you've got see Lightspeed. It's code may
not be the best in the world but it is a fast compiler and it
can't be beat as a totally integrated development environment.
I do major C development on VAX UNIX and VMS and there are no
tools in the same class as Lightspeed C. I believe they have
set a standard by which other environments can be measured...
Just my opinion, but I know of which I speak
Larry
From gatech!seismo!rochester!cornell!batcomputer!saunders Thu Apr 30 00:46:29 1987
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Aztec C has one significant advantage: the source level debugger,
which mostly works. Life with a Macintosh is easier with one of these.
LSC is said to be very fast. MPW might be an option also; the shell
is rather like a warped Bourne shell with the regular expression
metacharacters changed "to protect the innocent."
I'm not particularly impressed with their support. Then again,
I'm not particularly impressed with Apple!
????,
--
Kevin Eric Saunders
ARPA: saunders@tcgould.tn.cornell.edu
uw-beaver!cornell!batcomputer!saunders
From akgua!spuxll!ech Thu Apr 30 01:00:11 1987
:
I am no longer neutral on this question, as I went to work for Manx (who
publish Aztec) about 2 months ago, specifically to ENHANCE the Mac product.
Both packages are excellent. If your intent is casual use, the Lightspeed
package (at the going rate of $125) is hard to beat. If you're serious,
you'll find that the Aztec package will do far more for you and NOTHING
behind your back (the Lightspeed package mucks about with the system too
much), generates tighter and faster code, and will support the 68020 and
68881 (needed for max performance on the Mac II, if you care).
We are VIGOROUSLY developing the Aztec package at this time. The next
couple of months are going to see full MPW support and a Source-level
debugger in the package, full ANSI-standard by the end of this year, and
source-level optimization within a year from now.
I like 'em both, but I'm really EXCITED about the Aztec package.
=Ned Horvath=
From masscomp!wanginst!elrond!anson@gatech Thu Apr 30 18:46:57 1987
Organization: Calcomp Display Products Division, Hudson, NH, USA
:
I bought Aztec C about a year ago, and used it a lot. It was pretty good.
A few months ago, I bought Lightspeed C. I haven't used Aztec since.
--
Ed Anson, Calcomp Display Products Division, Hudson NH 03051
(603) 885-8712, UUCP: [decvax, wanginst, savax]!elrond!anson
From akgua!ihnp4!uiucuxc!uxf.cso.uiuc.edu!dal630 Thu Apr 30 23:53:28 1987
I have Lightspeed, Aztec 1.06h and MPW 1.0. I used to like aztec,
but it's getting old (no enums, bitfields, struct passing/return). Lightspeed
seems to be the only sane choice for mac-style application development.
Aztec has a niche as a vehicle to port unix stuff to the mac in a useful way,
and perhaps conversely as a way to develop unix stuff, although I have heard
of LSC used for that purpose as well. The new LSC stdio lib is more mac-like
and therefore looks better than the old "tty" style one.
MPW is a monster... I guess if you need it, you need it bad. You have
to retrain yourself coming from unix (different wildcards, etc...) but the
C compiler is great (even though it uses 32-bit ints).
I know of a guy who likes Consulair Mac C a lot, but I think that's
because he likes the support direct from the author.
summary: Lightpeed C
pro con
fast development cycle almost *have to* use mouse-based editor
lot of PD source available unix libs complete but not convenient
good development environment
Aztec
pro con
unix - like slow
good portability to/from unix awkward ROM inerface (ie. point passing)
can use vi clone or PD microEmacs
I haven't delved into MPW too much, so I won't comment
dave
ihnp4!uiucdcs!uiucuxf!dal630
From akgua!ihnp4!zehntel!zinfandel.UUCP!sam Fri May 1 00:11:19 1987
In response to your request in comp.lang.c: I have used Consulair C and
Light Speed C. I personally thought that the Light Speed compiler was
the better of the two. I've never used the Aztec compiler. The project
was rather large (technical desktop publishing system [not released yet])
with about 10 programmers. Considering that we did not have a network
of any kind (dismissing applenet as the little "computer joke" that it is)
for source managment. It was reasonably easy to keep the versions
straight using the subprojects feature. The compiler itself was pretty
quick (although you better have a hard disk) and linker screamed, probably
the fastest I've seen. The code quality was pretty good. Light Speed
in conjunction with TMON as a debugger made a pretty nice development
environment.
I am no longer on the project, so I can't say what impact (if andy) the
debut of the apple fileserver has. Anyway, hope this helps. I would be
interested in the results of your poll, if you get enough response.
P.S. In the above I didn't mean to imply that the Consulair compiler was
not a good compiler, I just personally prefer Light Speed after using both.
Date: Fri, 1 May 87 14:11:19 EDT
From: Reid.A.Ellis@unicus.com
:
... I have used Aztec C version 1.06h. Some of its
problems include:
can't have #includes more than three deep
Aztec "make" is not full make - file.o must be explicitly stated
to depend upon file.c
Compile time and code produced is somewhat underwhelming
Seriously, check out Lightspeed (for personal use) and MPW C (for
professional use).
Bye for now,
Reid.
--
Reid Ellis, aka Clith de T'nir
{seismo!mnetor, utzoo!yetti}!unicus!rae (uucp)
mnetor!unicus!rae@seismo.css.gov (arpa)
From rutgers!harvard!husc4!waldman@gatech Sat May 2 18:22:34 1987
Organization: Harvard Univ. Science Center
You asked for a comparison of LightSpeed and Aztec C. Well, right
off the bat, I think that LightSpeed C is the best C system available for
any computer. Development time is very fast, especially with a hard drive,
since LSC has an auto-make facility, recompiling only files that need to be
recompiled when you pick "Run" from the menu. The editor is superb, as well.
The only criticism that I have is that there is no source level debugger-you're
stuck with Macsbug or another such debugger.
I also think that the LSC generates better code. Here at Harvard,
we're developing a set of graphing programs to be used in second year calculus
classes. First, Aztec was used, and then we switched to LSC, with a real
improvement in graphing time--this makes me think that mathematical
calculations are better handled by LSC.
I hope this was helpful.
Ben Waldman
waldman@husc4.harvard.edu
...seismo!harvard!husc4!waldman
From lewis@HARVARD.HARVARD.EDU Mon May 4 11:27:28 1987
Your question is a really easy one. We developed three fairly
large applications here (15 source files, about 20 include files).
We started with Aztec because that was the best available at the time,
then we switched to Lightspeed when it came out. Lightspeed
is MUCH MUCH faster to use -- the integrated editor and smart
project management system is a real pleasure. The three programmers
I had working on this stuff wouldn't dream of going back to
Aztec. The libraries are just as complete as Aztec's, and all
the source code is provided, which has come in handy. Version
1.0 had a few bugs (fewer than Aztec had after a year in production)
but 2.0 is absolutely solid as far as I can seen. A great product
at less than half of what Manx charges.
We have been using Lightspeed C in a second-level programming
course this year -- Think agreed to make the disk sets available
at $30/student. This has been very successful -- the compiler
and (especially) the linker are fast enough that students are
able to develop big systems off floppies in short amounts of time.
As their final projects they are all writing Lisp interpreters,
complete with garbage collection, in 3 weeks. (Of course, these
are probably 20-30 hour weeks, but it's still impressive.)
(The exact configuration they are using is 512e with 800K internal
and 400K external drive. More disk space would be nice, but even
for this fairly large project this configuration is adequate.)
Disclaimer: I am probably biased because Mike Kahl, who wrote
Lightspeed C pretty much single-handedly, took introductory
programming from me so obviously he must be doing things right.
Seriously, Mike ranks with Bill Gates as being one of the smartest,
most aggressively perfectionist people I have known; he would
have been a good programmer if he had been taught by Bozo the Clown.
- Harry Lewis (lewis@harvard.edu, lewis@harvard.csnet)jww@sdcsvax.UUCP (05/29/87)
In article <2068@emory.UUCP., ospwd@emory.UUCP (Peter Day {EUCC}) writes:
. From gatech!seismo!cmcl2!nyu-acf2.arpa!siritzky Tue Apr 28 11:44:13 1987
...
. ... All of these C compilers
. will only allow you a 32K code segment - for the whole program. In our
. case this was way too little.
. I have since tried the MPW C. It is better than the others for my problems,
. although it still has the 32k limitation (I'm told that this is a problem
. with the Mac OS!).
...
. Brian Siritzky, C.I.M.S., 251 Mercer Street, New York, NY 10012
. ARPA : siritzky@nyu
. uucp : ...!cmcl2!acf2!siritzky
It is certainly possible to make programs with segments . 32K
with MPW C. The linker is quite keen on this, although any Macintosh 512
will crash when it sees one.
I believe your data segment is still limited to 32K, though.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news)
jww@sdcsvax.ucsd.edu if you mustearleh@dartvax.UUCP (Earle R. Horton) (05/30/87)
In article <3243@sdcsvax.UCSD.EDU>, jww@sdcsvax.UCSD.EDU (Joel West) writes: > In article <2068@emory.UUCP., ospwd@emory.UUCP (Peter Day {EUCC}) writes: > > From gatech!seismo!cmcl2!nyu-acf2.arpa!siritzky Tue Apr 28 11:44:13 1987 > >>> > > ... All of these C compilers > > will only allow you a 32K code segment - for the whole program. In our > > case this was way too little. ..... > It is certainly possible to make programs with segments > 32K > with MPW C. The linker is quite keen on this, although any Macintosh 512 > will crash when it sees one. > > I believe your data segment is still limited to 32K, though. Macintosh Kermit, aka CKMKER 0.8(34), has a resource of type CODE and ID 1 which is 63078 bytes in length. It has yet to crash my 512. In fact, this is a PARTICULARLY well-behaved program. This program was created by the sumacc C compiler at Columbia. I don't know which combination of 68000 C compiler and assembler / OS is run on the machine which created the program, or even what that machine is. I think this establishes that a code segment > 32k can run on the 512 (I think it runs on a 128, too). In any case, let me throw in my two cents worth on this subject. I have been writing code for 68000 (Mac) and 8086 (Intel 310) for two years now, and have grown quite used to the idea of segmented code. All of the development systems I have seen allow either 32k or 64k code segments, max, but they DO allow linking of several segments into one main program. I believe all the systems mentioned above for the Mac can do this (correct me if I am wrong). I do know that Lightspeed C can be used to create large multi-segment applications whose total code size is far in excess of 32 or 64k. The idea behind segmented code, as I understand it, is this: These two processors use two general types of jump/call instruction. There is a 16-bit offset jump, and a 32-bit offset jump. The 16-bit offset jump takes fewer bytes to implement, both for the "call" and for the "return", but it is limited in scope to the size of a 16-bit quantity--32k if signed, 64k if not. Smart compilers, linkers, programmers put closely related procedures in the same segment, and use the long form of the instruction for less frequent procedure calls. This is, of course, a simplistic explanation, I refer you to the appropriate manufacturer's microprocessor handbook for details. If you "go with the flow" and use segmentation for the purpose intended, you can achieve significant savings in code size, execution time, and development time. There is programmer effort involved, true, because you then have to decide which routines go in which segment (but that's the kind of thing flow charts can help with.) Segmentation on 16/32 bit machines can be viewed in either of two ways: It's a tremendous inconvenience to the programmer. OR It provides a convenient mechanism to enforce intelligent, structured programming. I guess it's all a question of attitude. As for the data segment, it is fairly simple to create more "data" segments on the Macintosh by using custom resource types. There are also dynamic storage, separate files with data in them, linked lists, the data fork of your application, need I go on? I hope this has been of some help. If not, you could have hit the 'n' key... -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
jww@sdcsvax.UCSD.EDU (Joel West) (05/31/87)
On a 68000, 16-bit address displacements are always signed, hence
32k.
MPW's default data segment is 32K. You can't have more globals
than that (I don't understand if there's a technical reason they
can't support multiple segments or longer segments, or that they
just haven't gotten around to it.)
Having two programs with segments > 32K could be a problem, since
the jump table for cross-segment references only goes 32K in.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel if I ever fix news)
jww@sdcsvax.ucsd.edu if you musttraffic@ut-ngp.UUCP (Wiley Sanders) (05/31/87)
As long as we're on this subject: two years ago I wasted $150 on a
copy of Hippo-C. Of course, the version I have is incompatible with
Systems 3 and above and from all I can determine the company long ago went
under. Does anybody know what has happened to these _________'s (fill
in your own derogatory term here)?
lose, lose
-w
--
Wiley Sanders, Civil Engineering Dept, UT-Austin
secret NSA CIA anti Soviet Iran terrorist nuclear drug decoder ring
- take THAT, NSA line-eater!daveb@geac.UUCP (Dave Brown) (06/01/87)
It is also possible to use more than 32k words of data under MPW:
If you allocate 2 or more segments, confirm that they are contiguous
and provide an assembler or in-line access function, you can manipulate
64k objects, where an object in this case is a struct of plausable size.
You would be well-advised to dispose of them carefully, though, and
make sure they aren't declared relocatable!
For an object called "memword", the MPW Pascal incantation was:
x:= memword(pointer(org4(base)+4*org4(index)));
This assigns x the address of the first byte of something called a
"memword" at &base[index], which happens to be 4 bytes long. (its easier
in c: the compiler doesn't frog on pointers to large things, just attempts
to create large things).
Incidentally, the code generated is only one instruction worse than
optimal: the multiply comes out as a shift, but an extra index-to-address
register transfer gets done, as the ord4() calculations are done in index
(general, actually) registers.
--dave (this limitation does NOT exist on Mac II) brown