Re. AW: [Oberon] DIV and MOD

eas-lab at absamail.co.za eas-lab at absamail.co.za
Sat Aug 9 10:59:51 CEST 2003


I've taken the liberty to move the top-posted answer to 'after' the
corresponding question, and cut LineLen < 80.


	>  Jacques Eloff wrote:
> > I recently noticed that the compiler (at least the 2.3.8 Linux version for
> > Intel) now attempts to compensate for fractions when performing signed
> > integer division, adjusting the result returned by the CPU. This requires
> > a minimum of three additional instructions and can create problems when
> > routines are written in assembler since the result will deviate in some
> >	cases
> > from what Oberon says the answer should be. Does anyone know what the
> > reasoning behind this change was?
> >
> > Previously, something like x DIV y (with x, y: LONGINT) would result in
> >
> > MOV EAX, x[EBP]
> > CDQ
> > IDIV y[EBP]
> >
> > but now, the compiler generates
> >
> > MOV EAX, x[EBP]
> > CDQ
> > IDIV y[EBP]
> > JGE done
> > DEC EAX
> > done:

"Stauber, Sven Philipp" wrote:
> According to "The Programming Language Oberon (Report)" the behaviour 
> of DIV and MOD (for any dividend x and a positive divisor) should be:
> 
> x = (x DIV y)*y + (x MOD y)
> 
> 0 <= (x MOD y) < y
> 
> The IA32 IDIV operation has a different behaviour. 
> The division rest always has the same sign as the dividend 
> (x IDIV y always rounds to zero, in contrast to the Oberon DIV which always 
> rounds down).
> 
> Example:
> 
> Oberon:    -5 DIV 3 = -2,     -5 MOD 3 = 1    ->    -5 = -2*3 + 1 
> 
> IA32:     -5 DIV 3 = -1,      -5 MOD 3 = -2    ->    -5 = -1*3 + -2 
> 
> If EDX is negative, the dividend is also negative and then DEC EAX is 
> used to "round down" the negative quotient which was rounded to zero 
> by IDIV. The IA32 code pattern for the Oberon MOD operation should look 
> similar (if EDX<0 then EDX = ABS(EDX)-1 else EDX ).

One expects these 'little problems' to appear with continual 'updates'.
And since ETH is a teaching institution it MUST continually update.
Heavy-duty USERS are perhaps wise to keep away from the
 'bleeding edge' ?

Don't 'test suites' (for the compiler) find such problems, rather than
hoping some user/victim will report falling in a hole ?
Of course for the school, one needs a continual source of problems
to keep the students busy/exercised.

What happened to the move towards formal methods, from 
decades ago ?

Via c.l.o a *.za.co poster  pointed to the "history of the development
of Modula ( & 2)", listing the many international conferences, where
some one was pushing for the 'Vienna formal method', which came to
nothing.

Is it just an absurd fantasy (as speech input is) to have a development
system which delegates the clerical job of source code generation
to an automata, to free the programmer for higher concerns ?

I had to use a W98-box to look at some *.rft and comparing it's lame
cutNpaste compared to n-o, I just have to ask "what marvelous
systems are out-there which I too don't use, because of inertia".

-- Chris Glur.




More information about the Oberon mailing list