Precedent for use of =

[Dan Smith]

     I've watched this discussion now for quite a while and finally cann't
stand it anymore.   I agree with Dave Haynie when he says that most people
who seem to have a problem with '=' are frustrated pascal programmers.  We
should start up some new discussions about C syntax or usage/and/or various
implimentations of C by companies.  I've done fortrash/assembler/pascal/c
in my checkered past and have found C's syntax to be quite clear (after you
read K&R)  Save us all from the 'Structure' freaks out there that cann't
do anything if they don't have a symbol or box to fit the construct.  My
main rule of programming which I always try to follow is "NEVER WRITE A
ROUTINE LARGER THAN ONE SCREEN"  Maybe its just me, but this works for me
and produces clean code which others can understand and work on.

    Enough of the soap box.  I'll prob' get a ton of flames for that but
my finger is getting tired of discarding mail about swap macros and '='
vs ':='.   Now lets get on to some new topics such as why several large
software houses have modified the syntax of pointer math on Intel 86
series machines to the point that it no longer fits standard C.  Most of
the C compilers which generate 'BIG' model executibles seem to have a
real problem with pointers.  Lattice put in code which converts to/from
a 'intel' pointer to a 'abstract' pointer to allow math to work OK but
at a performance cost.  Computer Innovations (at least at v2.3) use
'intel' style pointers only for the BIG model.  And pointer math takes on
a whole new outlook on life.  I've found that neither of these designs
works very well.  I've looked at the code generated by Lattice and its
QUITE offensive, it calls a subroutine for every instance of pointer
math to convert the internal pointer into a 'absolute' pointer then
converts it back.  Gross..  It would have been better to emit the code
inline and save a ton of overhead.  I tried my hand at it and came up
with about a 5 instruction convert in each direction which almost beats
the memory overhead of a arguement setup/call/arguement cleanup.  It
definitly beats it as far as speed.  These comments pertain to a Lattice
version about 8 months old and might be fixed now.

    I know my comments don't really fit the 'Info C' digest I guess it
should be in Info C Compiler Implimentations but I had to try and change
the course of current discussion.  I couldn't stand it anymore.  I guess
I'll have to put my flame proof shorts on now..  Oh vell...

"Std Disclaimer -- This stuff is the result of my own burnt out mind and
NOBODY elses"

Dan Smith (aka MadMan)
BITNET:     SYSBDES at TCSVM
ARPA:       SYSBDES%TCSVM.BITNET at WISCVM.WISC.EDU
UUCP:       ...psuvax1!tcsvm.bitnet!sysbdes
            real soon now !tu-pul!ludwig!ds
Ma Bell:    (504) 865-5631
Real Paper: Tulane University
            Tulane Computer Services
            Attn: Dan Smith, Systems Group
            6823 St. Charles Ave.
            New Orleans,  LA 70118-5698