LLL: asm version

[Francois-Rene Rideau]

">>>>" is Andy
">>>" is Mike
">>" is me (Fare)
">" is Mike again

>>>> 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.
Yuck. That's a hack and you admit it yourself. And I don't want any hack in
the system specificatins, or we'll end up with no better than Unix.
So you admit we *must* have assembler objects somewhere. The *only* way
to have it portably is to allow multiple versions. So why hide them, have
them being a hack, and forbid the normal user from using them ? What do you
gain at it ? Absolutely nothing, only a small satisfaction of a thoughtless
desire of believing your LLL is perfect. But you lose very much at performance,
plus dirty harmful code to manage your dirty hack, when clean useful code
would have been possible.

TUNES means TUNES, a Useful, Not Expedient, System.
I'll stick to this philosophy. Multiple versions are useful; we must support
them. But again, they are only needed for small routines where performance is
foremost and optimizers are not enough. Such routines are rare, but may be
added anytime by users as the system evolves; and however large your system
library may be, there will always be new uses that you won't even have
imagined for your system (unless it be dead), which require as much performance
as possible. So there is absolutely *no reason* why such routines should be
all included in the system kernel (if there is one -- I still see no need for
anything like a kernel, but to please M. Tanenbaum's terminology), and many
many reasons against (the biggest one again being that needs and routines
evolve, while a kernel should be stable, particularly in a persistent system).