lrh@ukc.ac.uk (L.R.Henry) (10/29/90)
I have just found a bug in sozobon top:- If dlibs is compiled with the -O flag then the library becomes completely broken If sprintf.c is compiled with cc -S -O sprintf.c then the following code is produced:- _sputc: link a6,#0 move.l 10(a6),a0 move.l (a0),a0 addq.l #1,(a0) move.b 9(a0),d0 move.b d0,(a0) ext.w d0 unlk a6 rts If compiled without the optimiser switch then the following code is produced:- _sputc: link a6,#0 move.l 10(a6),a0 move.l (a0),d0 addq.l #1,(a0) move.l d0,a0 move.b 9(a6),(a0) move.b (a0),d0 ext.w d0 unlk a6 rts Is there a fix for this bug. (I wont fix(I'm not an expert at C)) Luke.
nisimura@srava.sra.co.jp (Tohru Nisimura) (10/30/90)
In article <5940@harrier.ukc.ac.uk>, L.R.Henry writes;
I have just found a bug in sozobon top:-
If dlibs is compiled with the -O flag then the library becomes completely broken
If sprintf.c is compiled with cc -S -O sprintf.c then the following code is
produced:-
....
Do you use top v1.20, don't you ?
top v1.20 sometimes does his work under erroneus conditions.
When I got Sozobon v1.2 and recompiled my programs, I encountered the
same top's bug.
Is there a fix for this bug. (I wont fix(I'm not an expert at C))
....
Yes, I have it. I looked the output of top v1.20 closely, which was
more improved than top v1.01. Next, I inspected source codes of top,
and I found that there was room for more optimizations as well as its
bug.
I modified peephole optimization routines extensively. My personal
version top, namely v1.2x is currently stable, can produce an
(quite a bit) smaller/faster executables, and is free from the
above-mentioned bug.
I enclose a change note at the tail of this article.
Caution: the version is not official.
Other bugs:
In the course of my hack, I found other bugs of SozobonC. First,
jas generates incorrect codes for bit instructions: bchg, bclr, bset, btst
It is well-known bug. And, some routines in dlib1.2 have coding errors.
bzero.s has two errors, and memcpy.s does one.
Tohru NISHIMURA
Software Research Associates, Tokyo, Japan
Internet: nisimura@sra.co.jp
============================================================
Sozobon Optimizer v1.2x Change Notes
-- Oct 1, 1990 by Tohru NISHIMURA, SRA Inc., Tokyo
============================================================
This notes describes modifications about Sozobon Optimizer "top" v1.2x.
o General
Peep hole optimization is modified extensively.
a. chances to optimize are extended.
b. cases which seldom happen were deleted.
c. orders of case analysis were changed for fast decisions.
d. case analysis bugs were fixed.
e. "address register indirect with index" addressing mode
is used as much as possible.
o Problems & Fixes
1. top v1.20 sometimes does his work under unnecessary conditions.
=> Just a case analysis error: fixed.
2. Sozobon Compiler, "hcc", is too innocent about effective address
calculation scheme, especially for an element of structure array.
Array reference is done as follows;
a. calculate index
b. extend the value to long (with/without sign-extent)
c. add base address
d. move the result to one address register
e. make a reference using either register indirect mode or register
indirect with displacement mode.
This procedure is simplified with a MC68000 versatile addressing mode;
"address register indirect with index" mode. With this mode,
a reference to an element of struct array is done intuitionally.
top v1.2x uses the addressing mode as much as possible.
In best case, the optimizing effort saves 2 words space and a few
clocks for each instance. In worst case, it results in just an
exchange of operands between two instructions.
3. top v1.20 sometimes fails to optimize in spite of that it is
coded to do.
=> Some are due to case analysis error, others due to Sozobon C
convention. Former was fixed, latter not.
Description of latter problem: d0 register is used for returning
function result. top v1.20 blindly assumes that rts/rtd/rte
instructions refer to sp and d0, even if the function type is
void. This infers top's optimizing procedure. If a function
actually returns a value, there is no problem. Because value
assignment to d0 register is always preceding to rts/rtd/rte
(that is, d0 becomes "dead" near at the end of function),
thus intermediate d0 can be subject to optimize for top.
If the function returns no value, top would think d0 register is
being alive until the end of function. In this case, every
d0-relating optimization instances just preceding to rts/rtd/rte
will fail to work. To solve this problem completely, hcc must be
modified.
o Open problems
1. hcc should use "address register indirect with index" mode
for oneself. The efforts of top v1.2x will not work well in some
cases.
2. hcc does not utilize contents of registers at all. Effective
addresses are calculated on every instances, even if the same
value is alive in registers. This approach simplifies hcc,
but the elimination of common expressions should be done in
compiler, rather than optimizer.
3. code reduction with bit instruction; some code sequences can be
optimized using bit instructions, btst, bset.
For example,
if ((x & (1 << y)) == 0) ...
x |= (1 << y);
bit instructions cannot be used via C language directly, this kind of
optimization may be actually what optimizers should do.
4. register a2 and d2 are never used for any purpose. They may be
reserved for scratch registers, but I have never seen hcc used them.
top does not utilize them for "registerising".
--- end of change ---