Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <4397@cbmvax.UUCP>
Date: 1 Aug 88 23:17:02 GMT
References: <1988Jul22.164129.5495@utzoo.uucp> <4912@killer.DALLAS.TX.US> <4324@cbmvax.UUCP> <1988Jul28.171444.7068@utzoo.uucp>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 54

In article <1988Jul28.171444.7068@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <4324@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>>> ... The techniques are
>>>> not that well known (especially in the micro community, which is notorious
>>>> for its ignorance of the state of the art -- the people at Commodore most
>>>> likely had no idea it was even possible to do a fast software BitBlt).

>>	Excuse me, I have a paper in front of me published in EUUG last fall
>>by a researcher at AT&T on optimized software BitBlits in C on an 68020.

>I don't consider a 68020 a micro, myself.  The 68020 machine I am writing
>this on is much bigger and faster than the minicomputer I was using a
>month ago.  When I say "micro", I mean something that competes with PCs.

	True, but 68020 code is largely applicable to the 68000, plus the
paper included examples in pure C and in 68000.  And 68020's are about to
become considered micros.  (though you can build mini's out of them: the
difference between mini and micro is becoming a matter more of price tag
and I/O speed than processor type - and even those are fuzzy.)

	We do compete with PC's (actually, the A500 is positioned even
lower than most PC-clones, about $600).  However, we try very hard to be
much closer to "state of the art" than other micros (multitasking, semaphores,
blitters, etc, etc).  And our OS comes with the machine, it doesn't cost
you an extra $795 or whatever.  ;-)

>As for insulting the wrong people, if you're reading papers like that, I
>would consider you a (laudable) rare exception to the (deplorable) rule.

	The only reason it ticked me off was the direct reference to
Commodore (for whom I work on Amiga system software).

>>	Fast software implementations of BitBlit tend to be 2 sources, 1
>>destination blits (therefor 16 operations).  If you expand them to 3 sources,
>>1 destination (256 operations), they tend to take up a LOT of code/ROM
>>space, or they slow down a lot, or both...
>
>This is where dynamic compilation, the original subject of this conversation
>(remember back then? :-)) wins big:  you don't need to duplicate all that
>code N times, just know how to generate it.

	Well, you need to revise your algorithms.  The paper I cited, for
example, uses effectively "canned" code pre-compiled by the compiler.  Quite
amusing code to read, it does truely evil things with the macroprocessor,
but is more or less portable (and almost entirely in C, though the fastest
version has one or two #asm's in it).

	It means you have to REALLY do code generation on the fly, if you
need 256 operations.  Not impossible, but much more of a pain to write/
support.  Having a compiler do most of your work for you makes things much
easier.  :-)

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup