Marcel,

There is no need to be worried - we will always have the general BitBlt code
around since there are always chances that we don't speak a certain assembly
dialect (I don't speak MIPS, nor SH3 just for the matter of some WinCE
hardware). It does make, however, quite a difference in speed if you have
the option to do a bit of native code generation (as an example, a trivial
native code implementation of the most optimized inner loop of BitBlt
yielded a speed improvement of a factor of two). Since we can put stuff like
this into external modules we should be able to live in the best of both
worlds - e.g., if you look at the startup of J3, then you'll find that the
VM goes looking for a Jitter and if there's one it runs it. If not it just
goes into the regular byte code interpreter and exactly the same could be
done for BitBlt. Also, Ian's CCG helps a lot with writing native code
generators that are accepted by the vast majority of C compilers. That way,
one never has to rely on the specifics on inline assembly or somesuch
(meaning that once you've got a native implementation for a certain
processor you've captured pretty much all of the available OSes for this
platform).

  Andreas

> -----Original Message-----
> From: Marcel Weiher [mailto:marcel at metaobject.com]
> Sent: Wednesday, December 08, 1999 3:38 AM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: RE: [enh] rgbMap:from:to: caching result.
> 
> 
> > From: "Raab, Andreas" <Andreas.Raab at disney.com>
> >
> > PPS. Of course, all of this will be "yesterday's snow" (as we say  
> in German)
> > once we're getting to JITBlt (which is yet another project, 
> heh, heh). 
> 
> I have to admit I am a little worried about all the emphasis on JIT  
> code generation, with all the issues that go with that.
> 
> Marcel
>