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