From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Date: Fri, 14 Aug 1992 16:52:11 GMT

In article <1992Aug12.173328.7160@cybernet.cse.fau.edu> spc@pineal.sci.fau.edu (Sean 'Captain Napalm' Conner) writes:
I said, of C programmers:
> >But they only have to do it once.

> But what about the code you #ifdef out, don't you have to re-write that part?

Only if you find it's not fast enough.

> Also, I have C code to view ILBM image files (on the Amiga).  I would like
> to port the code to my Unix workstation.  But the code is SO Amiga specific,
> the entire thing would be #ifdef out!  (Or should have the original
> programmers assumed that at some time the code WOULD be ported and written
> it thusly?

Yes. You can write non-portable code in any language and on any system.

That's how I write *my* amiga code. I even shipped a (fairly popular) video
game that was still using "malloc" because it wasn't worth it to change them
to AllocMem to speed things up. Even on a 500 I was slowing it down to keep
it playable.

On the other hand there's one game my wife plays, and I bought the source
so I could modify it for her. I finally gave up after a couple of days trying
to port it from one C compiler to another, on the same machine.

You can write non-portable code in C, but you can also write portable code.
You can't write portable code in assembler.

> Does that mean I 
> have to assume that at some point, my code is to be ported to either a) DOS
> (640K upper limit for everything) or b) some Wiz-bang multi-parallel 500GHz
> Transputer using photons instead of electrons, that will be built in 10
> years, but only code written with a certain style can be compiled on it?

Yes. At least try to code things so it's easy to perform surgery.

> What is safe to assume?)

K&R1. The more C environments you're familiar with, the more portable code
you can write, but for the next few years it's not safe to assume more than
K&R1.

>   -spc (Unix philosophy:
> 	1. Write cryptic and highly customizable code.

Write simple code. Write small modules that hang together well. Write your
code as generically as possible... one day you'll have to port it.

> 	2. Never write original code.  Find some that's close, and force it.

I've seen some of that.

> 	3. Never write C.  That's what Awk and Perl and Bourne Shell are for.

If an interpreted language is fast enough, sure.

> 	4. Never write Assembly.  That's what C is for.

If a compiled language will do the job, sure.
I've got assembly modules in some of my current code, but it's pretty
hairy stuff.

> 	5. Never remove code.  #ifdef it out.

I don't hold with this. If I change the functionality of a routine, all
the ifdeffed stuff is either brought up to date or dyked out.

> 	6. Write sloppy code.  The compiler will optimize for you.

Write good algorithms before you worry about micro-optimisation.

> 	7. Never worry about memory.  It's virtual anyway.

Oh, this is the MIT/Berkeley philosophy. Don't check the return code of
malloc. Assume your network is fast and your workstations are slow.

> 	8. If it's not running Unix, it's not a real computer.

If you can't run UNIX code on it, it's not a real computer.

>       (Personally, I can't stand the Unix philosophy 8-) 8-)

I can't stand people confusing MITnix with UNIX.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180