Synthesis and Re: LLL

[Mike Prince]

On Sun, 18 Dec 1994, Juliusz Chroboczek wrote:
> > is J. Van Schalkwyk (JVC) <SCHALKW@odie.ee.wits.ac.za>

> >                       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...
     ^^^^^^^ you mean wonderful?  I'm not that up on my french.  And it 
isn't in my small french dictionary or my large english one.  Anyways...
(Please forgive my lack of linguistic diversity =)

>   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)

I beg to differ, it DOES exist, just in forms we don't usually look for.  
Is a 486 a set hardware description of a microprocessor?  Kind of.  There 
is a "standard" 486 instruction set.  But the hardware that executes it 
can come in many forms.  Intel was kind of bummed with AMD for using it's 
microcode in 386 machines to execute the x86 "LLL".  AMD as well as many 
others now have 486 clones that execute 486 LLL with their own home-grown 
microcode on their own home-grown architectures.  Very different machines 
but what saves them is their ability to run the LLL (486 machine 
language).

We can (and are about to) do the same thing.  Just at a little higher level.

> > 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).

This is up for debate.  JVS says 32's, I say 8/16/32/floats, is there a 
third and what are your reasons.  An abstract pointer is just that, 
abstract.  We're dealing in concrete here.  Remember when moving data 
between machines we must have standards.  Now is the time to set them.

> > 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?

Please don't set your wild dogs loose on JVS.  He was just clarifying the 
forthcoming pseudocode.

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

Again, read the post carefully.  He was showing us one way using familiar 
x86 conventions so it is easier for us to read.  No, we are not defining 
machine code for one single machine, and you should know that.

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

Efficiency is VERY relevant.

> After that, we get an
> exaple of compilation techniques worthy of the first weeks of an
> undergrad course.

Are we trying to make friends or what?  I'm really tired of people taking 
pot-shots.  Add something, do not detract!

> > 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.

Nah.  He showed us the beginnings of our LLL.  I stand by him.

> > 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.

I hope I did not do any unnecessary flaming.  Many of our ideas are more 
than skin deep.  Read between the lines, and suggest improvements.  JVS 
has gone out on a limb with these suggestions.  They should be improved upon.

Mike