negative integer division

[Mike Meyer]

Jive Dadson <jdadson at yahoo.com> writes:

> Mike Meyer wrote:
>> [C] isn't - it's a portable assembler.
>
> I've heard that many times, but it makes no sense to me.  By definition,
> the syntax of an assembly language closely resembles the format of
> individual hardware instructions for a particular processor.

Um, no. The syntax of an assembly language is totally unrelated to the
format of the individual hardware instructions for a particular
processor. Typically, the syntax of an assembly language is such that
one obvious syntactical element (for instance, a line) generates one
hardware instruction. Usually, mnemonics of some kind were used to
denote which instruction to generate. However, it doesn't have to be
that way. Whitesmith had a z80/8080 assembler in which you wrote "a +=
b" to add the contents of register b to register a.

> An
> assembler assembles individual hardware instructions.  Back in the day,
> Unix (written largely in C) and Steve Johnson's pcc (the *portable* C
> compiler) together constituted a big leap forward.

A big leap forward *from assembler*. The development space that C
occupied at that time was the kernel and system utilities - things
that were usually (though by no means always) done in assembler before
the arrival of C. As a tool for producing robust, reliable code it
pretty much sucks, because it has so many of the flaws that assembler
has. Calling it a high level language is a disservice to the HLLs of
the era.

> Implementing Unix on
> new processors was infinitely easier than porting OS's written in
> assembly language.  So I disagree on two counts: C code is not entirely
> portable, (for example, division and mod may not work the same on two
> different machines), and a C compiler is most certainly not an
> assembler.

No language is entirely portable. C is *much* more portable than the
assembler languages that it displaced.

Note that C has displaced assembler in other areas - for instance,
it's not uncommon to find compilers that use "ANSI C" as the target
machine. By using C as a portable assembler instead of generating
machine code, the number of supported platforms increases
dramatically.

>> Now, I'll agree with you if you want to argue that some machines do
>> negative integer division in stupifyingly horrible ways.
>
> That's why I think it was a stupifyingly horrible decision.
> Understandable, but in the end an s.h.d. nonetheless.  It would have
> been okay to define / and % correctly, in the mathematical sense,
> but also provide functions quick_div() and quick_mod() that were
> guaranteed to work correctly only when both arguments were positive.
> The way they did it is just too error prone, akin to early
> optimization.

The way they did it was exactly right for the target applications
(i.e. - the v6 Unix kernel and system utilities).

> It's bitten me before, when I was called on to port
> code (which I did not write) from one machine to another.

There is no such thing as a portable program - merely ported
programs. I've been bitten by the code assuming that ints were two
bytes long, and know of cases where people were bitten by code that
assumed that chars were 8 bits. The simple fact of the matter is that
these things - like the behavior of the low-level div and mod
instructions - change from machine to machine. You have to deal with
such things when you are writing what is basically assembler. If you
were using a real HLL, none of these things would be a problem.

> Having standard operators with
> under-defined behavior is just inviting trouble: long debugging
> sessions, or worse, unexplained failures in the field.  Of course you
> and I would avoid all the pitfalls at the start. :-)

It's no worse than having standard types with loosely defined
sizes. That's part of the price for working that close to the machine.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.