LLL: asm version

Mike Prince mprince@crl.com
Tue, 1 Nov 1994 12:22:14 -0800 (PST)



On Tue, 1 Nov 1994, Francois-Rene Rideau wrote:

> ">>" is Andy
> ">" is Mike
> >> I would discourage the use of multiple code versions in a single 
> >> executable - it seems at odds with the philosophy of "one binary for all" 
> >> which is so central to the project.  Also if these objects are to be 
> >> migrated then keeping the size down is an important consideration.
> > 
> > Agreed.
> Well, I don't agree completely. Most of the time, multiple versions are
> not needed, and I agree that systematic use of multiple versions is quite
> harmful.

> But when it comes to very heavily used routines (e.g. graphics
> drawing routines, interrupt drivers, etc) where speed is important, we
> should have a way to give preformant routines. This will be used mostly
> for libraries, that will already be present and won't have to be migrated
> anyway. Moreover, if we use fine-grained objects, these equivalents will be
> very small.

I mentioned a work around for that in one of my original posts.  However 
I still stand by my opinion that the view of an object should only 
include on version of the code in our LLL.

The work around, is what I call specialized platforms (for lack of a 
better term).  For certain applications, such as graphics, the graphics 
board would include "fat" binaries as part of it's kernel software.  
These would expand to appear as normal tools/tool boxes.  These fat 
binaries would contain hardware specific code to optimize their 
performance, and would either be locked to the workspace (kernel) or 
provide a LLL equivalent, for migration.

This would be a kernel hack, but in cases of specialized hardware 
(graphics accelerators) it would solve our problems.  Remember though, 
that the only people who would even need to know about this hack is the 
kernel writer for that specific machine.  The OS would still look 
consistent to everyone else.

> BTW, have you considered that by using constant/slowly changing objects,
> you can have multiple copies of them spawn accross the network ? That's

What do you mean by slowly changing objects?

Mike