🚀 go-pugleaf

rickert@mp.cs.niu.edu (Neil Rickert) writes:

>In article <9104190111.AA00321@ucbvax.Berkeley.EDU> <phil@ux1.cso.uiuc.edu>
        writes:
>>I notice that very very little assembler language programming is done on
>>UNIX systems.  In part this is due to the fact that UNIX makes it easy to
>>do system level functions in C and other languages.  But there is also the

>  And in part this is due to the fact that the system features you would use
>assembler programming on in say MVS do not even exist in Unix.  (I think
>for example of the ENQ/DEQ functions for interprocess synchronization, or
>the ability to create channel programs for a device not yet supported by
>the operating system).

UNIX does have syncronization facilities.  But these facilities are different
in ways that reflect the nature of what UNIX is.  For instance if you want to
make sure that you don't end up with TWO processes concurrently trying to work
on some sharable resource, you need to syncronize the processes in some way.
UNIX does in fact need to do this, and has a means to do so.  More often than
not (outside of the kernel) the sharable resource is a file or device.  Thus
it makes sense to have a mechanism to lock files (devices are accessed via the
file space in UNIX) directly.  But if you need to share something else besides
a file, it's no big deal to make up a null file and lock on it anyway and this
is readily done in C (though not so readily in shell scripts I have found out).

Channel programming is needed more than it should be needed.  IBM has always
taken an approach to passing much of the detail of device control to the
application in its operating systems.  Applications have to typically at
least deal with things like the block size (and you have OPEN exits in MVS
and CMS to let you do it in assembler).  UNIX takes the opposite approach.
You never (very rarely anyway) need to deal with a disk blocksize just to do
I/O to a file.  You need to when dealing with tape because of the nature of
the data, but even then you can get away without dealing with it when sharing
data with another UNIX application that has done so.

My point is that assembler is easier on some systems, and it is NEEDED on
some systems, and it is NO coincindence that these happen to be the SAME
systems.

>  When it comes to optimization, things are not always what they seem.  I
>remember a few years writing the same program in Assembler, PL/I, and
>FORTRAN.  I looked at the generated code for each compiler.  Like all
>compiler generated code it looked pretty cruddy.  But in the innermost
>loop my hand optimized assembler code had only one less instruction than
>the FORTRAN code (at that time using the H-extended compiler with maximum
>optimization).  The PL/I code had more than twice as many instructions in
>the innermost loop.

For many things I have found this to be the case as well.  I've learned to
recognize when it does me no good to use assembler instead of Fortran.
Still in other cases it makes a big difference.

Since we are bashing PL/1 I might mention a program a friend of mine wrote.
He wanted to take each byte in a file and reverse the order of the bits.
He did this the "obvious" way in PL/1 by defining a bit structure and taking
each bit out one by one and putting them back in another one in reverse order.
He discovered that his program ran "horribly" slow.  It processed a file of
1000 80-byte records in about 75 seconds of CPU time on a 370/158.  I wrote
the same thing in aseembler.  Not knowing the linkage to PL/1 at the time
(due to lack of documentation for students, which is another issue) I wrote
the whole thing in assembler using TR.  It took less than 1 second.  Doubling
the size of the file didn't even seen to affect the time, so I suspect it was
running under the "noise".

BTW, looking back at my days as a student, I realize that in those cases where
there was a lack of documentation, I ended up working around the problem by
doing things in ways that would not make sense in a professional environment.
It took a while to UNLEARN all the wrong things I learned in school just
because someone in the computer center was paranoid about me "learning too much"
about the system and keeping back documentation.  I would really like to stamp
out that attitude.  There are times when assembler is appropriate and there are
times when it is not.  Students should be allowed to learn what these are.

> I also remember a few years ago talking to someone at a highly Unix oriented
>company which happened to also run a large IBM/MVS shop.  I thought this
>was strange, so I questionned it.  The reply was that FORTRAN was used in
>their chip design software, and no Unix FORTRAN compiler came close to
>matching the optimization provided by the IBM compiler.

The Fortran compiler is the toughest one to beat.  It *IS* beatable by good
assembler programmers, but the benefits of trying to do so are reduced now
because:

    1.  The margin is getting narrower with better compilers.
    2.  Processors are caching better making the difference between
        good code and bad code smaller.
    3.  You just can't justify doing this with 1,000 to 100,000 line
        Fortran applications anyway.

So you probably want to stick with optimizing the bottlenecks ONLY, once
you determine where they are.  More often a good choice of mathematical
algorithm can improve things more than rewriting in assembler, depending on
the scale of the problem and the machine.  For instance there is a way to
do a 2x2 matrix multiply with only 7 instead of 8 multiply instructions,
at the cost of doing a few (5 I think) extra additions.  You can recursively
extend this to larger matrices with eventually a tremendous speedup.  But
this is only going to do you any good when a multiply costs more than an
add.  Some chips are now doing BOTH in one cycle.
--
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/