Synthesis and Re: LLL

Juliusz Chroboczek jch@clipper
Sun, 18 Dec 1994 21:20:30 +0100 (MET)


> is J. Van Schalkwyk (JVC) <SCHALKW@odie.ee.wits.ac.za>


  As you might remember, I tried to prove, before the W.-E. that your
hopes I completely mirific.  JVC's answer seemed to imply that he
agrees with me on everything, but arrives to completely different
conclusions.  I have to say that I don't really understand his
reasoning.

> The reason why _I_ve been forced down to a lower and lower level is 
> simply that, although several languages (eg LISP) have very desirable 
> features, and have indeed tickled my fancy, NONE has come up to 
> scratch when it comes to getting down and doing some really serious 
> work (especially as the OS is quietly fucking you underneath, all the 
> time).

  What do you mean by doing really serious work?  Coming to scratch?
Quietly fucking sb. underneath?  (I do understand what fucking is
about, but I have trouble imagining fucking quietly :-) ).
  More seriously, I believe serious work *can* be done in Lisp (next
time you try to imply the opposite, I flame you!).

  In the same message, I tried to explain that having a common LLL is
impossible because of the variety of HLL *and* of hardware
architectures.  You aggreed with the former, but did not speak about
the latter.  I shall elaborate on this while commenting your LLL
proposition.


>                       There will be deeper (transparent) machine 
> dependent code on each & every machine, but the concise, powerful LLL 
> unifies all. Above the LLL you can have a hierarchy (or whatever) of 
> more abstract constructs. 
  Isn't this a non sequitur?  I thought I just proved that such an LLL
is mirific...

> Can we not have efficient core code (DNA has 4 different bases 
> grouped in triplets) that is simple; fairly complex intermediate 
> levels; and then a fairly well-defined, useful building block (the 
> cell) that encapsulates a lot of hidden processing power, but is 
> nevertheless small enough to be useful? 

  DNA is at the hardware implementation level (it is the actual means
used to store information); the right analogy would be the use of
magnetic material for storing information on disks.  Non relevant to
the discussion.

  In another message, you wrote about the
> PROPOSED CORE CODE FOR IMPLEMENTATION OF LLL
  Very good proposition, but not for a doubly universal LLL
(i.e. independent of both the application area and the target machine
architecture -- my opinion is that such a beast cannot exist), but for
the actual assembler of a certain machine; that is *not* what we would
like.
  A few examples:

> All references are to DWORDs (32 bits)
  Why?  I'd like the code to work on a PDP-11 (18 bit words).
Furthermore, you are implying that the machine has a flat memory
model, and that addresses are represented with integers (I'd rather
favour an approach with an abstract 'pointer' object -- thus making
the LLL dynamically typed).

> All numbers are hexadecimal
  Is that relevant to the topic of the discussion?  Aren't you mixing
the definition of the language with the syntax of the assembler?

> Naming and operand conventions are 80X86 flavoured
  Exactly my point: you are defining a machine code for *one* single
machine.

> b. Registers, Stacks, memory
  Where's the distinction between registers and memory?  If it's only
one of efficiency, it is not relevant.

 [follows the list of all instructions, and an operationally-oriented
very informal explanation.  Nothing is defined.  After that, we get an
exaple of compilation techniques worthy of the first weeks of an
undergrad course.  Follows a more interesting section on the concepts
that Fare introduced informally, which are now translated into the
proposed assembler notation]

> Am I being too simplistic?
  Nope.  You have the right approach to solving a different problem.
You did not design a LLL, you simply created an example assembler in
order to show us how Fare's concepts can be implemented on traditional
hardware.

> Any comments?
  I just hope I did not sound to much like flaming.  If I did, please
forgive me, and remember that English is a (very) foreign language for
me.

  Merry Christmas!

                                     JCh