TUNES documentation comments & misc questions

[Francois-Rene Rideau]

>    I am impressed at the amount of time and work that you've clearly
> put in on this project, so far.
   You shouldn't: I do like to think that I have put a fair amount of
original ideas in this project, but I have to bitterly admit that actual
work is what the project lacks most.

> For about how many years have you been involved with TUNES?
   Hum. Difficult to say. Somehow, I've been thinking about it this I began
programming and was disappointed by the deeply rooted stubbornness of
available computer tools. The TUNES project itself began on late '94.
As you see, the yield has been poor :( :( :(.

>   About how many are on the mailing list?
   Again, the yield is poor. There are 46 people listening (or at least,
there were that much people subscribed last time I checked, one week ago),
but few are speaking (five at a time has been the max, I think),
and fewer even working (half a person, I'd say, including myself).

>   About how many hours per day do you put in on it?
   Greatly varies, and not enough, seemingly.
   I want all the code I produce to be perfect, so my code yield is poor,
plus I have great difficulties to begin when I write anything but e-mail or
draft notes.

>   Would you care to make even the vaguest estimate for a scheduel on the
> implementation of TUNES?
   Last time I cared, I was false. When the year is well begun, I'll try
give another, better one.


>   Has a specific course of action been mapped out in order to deal with some
> of the most significant difficulties?
   The most significant difficulty is: having me (and/or niftier guys)
actually work for TUNES and experiment. I know no remedy to this problem yet.


> Do you frown upon the usage of assembly language in TUNES objects?
   Why should I ? On the contrary, it should be not only enabled, but made
as easy as possible (while fulfilling the other system constraints), for such
objects are often necessary, as founding items for various parts of the
system, and/or routines that will transform sluggish computers into decent
ones, and save people from spending incredible amounts of money to "upgrade"
their computer hardware when they needn't, while making the most out of
actually upgraded hardware.
   However, once the system is developped enough, assembly will eventually
prove a quite suboptimal tool for most task: it is very poor as for
portability, scalability, adaptability, provability. People will tend to
rather use a high-level language, and use programmable optimization tactics
to direct the compiler toward better code generation. e.g. one would tell the
compiler something like:
* "try to implement these as arrays, to interleave those two arrays and more
 to achieve power-of-two element size while wasting as few bytes as possible,
 and align the beginning minus offset to a 64KB boundary (or better, put it at
 address 0)", or
* "try to use a barrel-shift register instead of an arithmetical counter for
 this bit-mask loop", or
* "transform incremental counting into decremental counting to skip a compare
 instruction", or
* "try these megafast implementations under various known contexts (CPU,
 calling convention, or any restrictive predicate)", or even
* "send that unformal code specification down the usual trail to the
company that offers commercial coding services and support, so they make
great computer code out of this stuff".
   Such tactics would prove much easier to use, much more portable, much surer
as for efficiency (if tactic fails to yield better code, it can be
semi-automatically ignored), faster to tweek, and more importantly wouldn't
tie code to old hardware or software hacks.
   True gurus and hackers won't write much assembly code anymore if any, but
rather write meta-assembly code, that is, generic optimizing tactics that
apply to the specific code they write, but will apply automatically to many
other routines, and (more interestingly) to the next enhanced version of the
code that they'll be writing someday.
   Days of doing manually will be gone, days of meta-doing will begin. Much
like people don't hand-compute astronomic or physical stuff anymore, or wash
their linen by hand, or have portraits painted to fix their image, or
They have machines do it, and can focus on more interesting stuff, be it
manipulating astronomical equations, building washing machines, shooting
pictures, etc, or anything else that gained free time allows. And even these
activities will one day be semi-automatized if it brings valuable enough
enhancements.

   I'll try to expand on that in the TUNES documentation.
Where in it do you suggest I should ?

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"