Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!styx!mordor!sri-spam!sri-unix!hplabs!sdcrdcf!randvax!obrien
From: obrien@randvax.UUCP (Michael O'Brien)
Newsgroups: comp.lang.smalltalk
Subject: Re: BS on sun-3's, fix for multiplication primitive
Message-ID: <699@randvax.UUCP>
Date: Thu, 20-Nov-86 12:24:36 EST
Article-I.D.: randvax.699
Posted: Thu Nov 20 12:24:36 1986
Date-Received: Fri, 21-Nov-86 22:18:04 EST
References: <255@unc.unc.UUCP>
Reply-To: obrien@rand-unix.UUCP (Michael O'Brien)
Distribution: net
Organization: Rand Corp., Santa Monica
Lines: 60

In article <255@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes:
>
>I know some people out there are wondering about running BS on
>sun-3's.  For those that haven't been able to get this going, here
>is a hint or two.
>
>We got BS running on a sun-3 mostly just by recompiling the sources
>(sun-3 a.out format is different, remember?).  My recollection is
>that this is straightforward, i.e., no strange machine dependencies.
>
>There is one thing that had to be changed.  Several of the BS
>modules are compiled to produce assembly output, then an 'awk'
>script is used on the intermediate assembly (before running it
>through the assembler) to do some form of peephole optimization.  To
>make a long story short, the 'awk' peephole optimization doesn't
>work;
>...
>cheers,
>
>txr

Well, I've kept the "awk" stuff; I just fix it up for each new compiler
I come across.  There's a test in the optimized switch statement to see
if the target is > 256.  Since these are bytecodes, it never is.  The
"awk" script is supposed to get rid of this in the two big byte-code switches
(one for blocks, one for methods).  It's unclear to me how much good this
really does but since the switch occurs for every bytecode I've just kept
it, adjusting the script for the location of the test & branch instructions.
Principle of minimal fiddling and all that.  There's an "asm()" in the
source to stick a comment in the assembler output to mark the location of
the switch code.  Life got real interesting there for awhile when there
was a compiler whose optimizer stripped out the comment, and the "awk"
script had to locate the switch by pattern-matching the code, but that's
what keeps life interesting, eh?

Interestingly enough, the 3.1 and 3.2 C compilers seem to have an optimizer
bug that bites these same two modules, independently of the "awk" thing.
After days of boiling code down, and several go-rounds with Sun, it has
been discovered that "execBlock.c" and "execMethod.c" can only be optimized
by calling "c2" directly with the flags "-dcoalesce -dshorten -20", at
least for Sun-3's.  The last argument is obviously for 68020 stuff, but the
first two arguments turn off the broken optimizations.

A more serious problem under Sun OS release 3.0 is the fact that the
Notifier won't let you get up-down keycodes any more, though I've heard
they've had their heads bashed real good and you can do it under 3.2...I haven't
seen that yet.  In rage and despair I just reloaded the keyboard mapping
tables for shifted, controlled, and caps-locked keymaps to be the same as
unshifted, which gave me the same keycodes every time, AND unique codes for
every key.  I reload the maps when I exit.  I will junk all of this when we
move to 3.2, with a prayer of profound thanks.

The multiplication fooble is news to me.  Thanks, Tim!  Didja ever get the
process stuff in BS II to work?  I just love software archaeology!
-- 
Mike O'Brien
The Rand Corporation

{sdcrdcf,decvax}!randvax!obrien
obrien@rand-unix.arpa