[net.micro.amiga] Using Astartup.obj instead of Lstartup.obj, C Philosophy

dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/14/86)

	As you all know, using Astartup.obj instead of Lstartup.obj means
you don't have to include lc.lib (for lattice users).  I've been able to
reduce many of my programs from 13000 to 2000 bytes in this way by 
writing my own 'stdio' library.

	It also means that many 'unix' functions are not available to you
anymore unless you write them yourself (e.g. as a library).  However,
amiga.lib contains back-off versions of some UNIX functions, such as 
printf.

	Could someone at C-A post a list of functions contained in amiga.lib?
They don't all seem to be documented.

					-Matt

---------------
Note on 16/32 bit int compiling:

	I myself use 32-bit int compiling exclusively (maybe because I only
have Lattice C).  A lot of my code reflects this by the general assumption
that pointers are the same size as ints.   Frankly, I don't care a whit 
about portability because I have found, over the years, that porting
somebody else's programs to a different machine (example: BSD4.2 to PC-XT)
usually requires a major overhaul. 

	In addition, many programmers who DO follow strict typing STILL 
assume int's are 32 bits (those who work with 32 bit compilers, that is),
and that assumption can lead to many hard-to-find problems which have nothing
to do with pointers WHEN you are porting from 32 to 16 bit compilers.  For
instance, loops, or system calls (the seek() between UNIX and micro's, and
even System 5, was a classic problem).

	I just assume the machine I'm porting to has a 32 bit compiler on it.
Don't get me wrong though... If I intend to write a general program which
sticks to simple OPEN's and STDIO that would be useful on any machine, I'll
write it portable and strict.

	In the case of the Amiga, with all the totally custom libraries 
etc... I don't see any reason to stick to strong typing.  The code will
never be ported to anything but a later version of the Amiga, a Mac, or
some other 32 bit machine.

	And besides, 16 bit machines are going out the door... when, in
a decade, 32 bit machines go away in favor of 64 bit machines (or whatever),
my code will be completely upward compatible.

						-Matt

grr@cbmvax.cbm.UUCP (George Robbins) (06/16/86)

In article <8606132340.AA09523@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes:
>
>Note on 16/32 bit int compiling:
>
>	I myself use 32-bit int compiling exclusively (maybe because I only
>have Lattice C).  A lot of my code reflects this by the general assumption
>that pointers are the same size as ints.   Frankly, I don't care a whit 
>about portability because I have found, over the years, that porting
>somebody else's programs to a different machine (example: BSD4.2 to PC-XT)
>usually requires a major overhaul. 
>
>	I just assume the machine I'm porting to has a 32 bit compiler on it.
>Don't get me wrong though... If I intend to write a general program which
>sticks to simple OPEN's and STDIO that would be useful on any machine, I'll
>write it portable and strict.
>
>	And besides, 16 bit machines are going out the door... when, in
>a decade, 32 bit machines go away in favor of 64 bit machines (or whatever),
>my code will be completely upward compatible.
>
>						-Matt

Matt,

	The Berkeley in you is showing.  If you have a machine that has
a 16 bit processor, runs faster with 16 bit operands and generates
smaller code, it is just plain lazy to say 'looks like 32 bits to me'.

	As you pointed out, assuming that pointers and integers are
the same length cause no end of portability problems.  The people who
decided that an int on a VAX should be 32 bits did the micro-world a
big disfavor, and the doubled it with a 'nothing smaller than a VAX
is worth worrying about...' attitude.

	Call a pointer a pointer, and an integer an integer (oops,
I mean a short)...
-- 
George Robbins - now working with,	uucp: {ihnp4|seismo|caip}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

mykes@3comvax.UUCP (Mike Schwartz) (06/16/86)

I have been training myself to use long instead of int in all my 'C' programs
lately, but I agree with Matt in a lot of ways. I do not care
if my Amiga software ever runs on another machine - there just aren't any 
around today that I even care about besides the Amiga.  So if the Amiga is
where all software is going to be ported to, why worry about things like 
16 bit or 8 bit machines and their LIMITATIONS?  The main remaining question
is whether this style of software will be difficult to get running on the
A-5000 (or whatever) that will be available in 5 years.