Juliusz, old chap!

[Dr. J. Van Sckalkwyk (external)]

Dear Juliusz

> hopes I completely mirific.  
{?}

> JVC's answer seemed to imply that he..
I am not a VCR (JVS)!


> agrees with me on everything, but arrives to completely different
> conclusions.  I have to say that I don't really understand his
> reasoning.
1. It is not possible to create a platform that will run everything,
always, faultlessly.
2. I do believe however that  it IS possible to create a "symbolic
assembly language" (convention) that can be used on most (all?) 
current machines. Good assembly language programmers only use a small 
proportion of the wide variety of instructions available on most 
current processors. You only _need_ a small selection of instructions 
to execute most tasks.
3. This symbolic assembly language can then be used to create HLL(s) 
that do useful work on all the machines, with a common "core". I do 
_not_ mean that you can now take code in any arbitrary language and 
exepct it to run faultlessly in "our" system.
4. The simpler we keep things, the more likely we are to succeed.
5. If you have formal proof that the above is bullshit, please submit 
it.
6. If however, you merely _believe_ that I am talking rubbish, and 
have nothing substantial to contribute, don't waste your time with 
this group!

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

1. really serious work. Well I don't know. Maybe I've never really 
done _really serious work_ in my life! The last (trivial) job I did 
was a little program for a specialist cardiologist that enables his 
secretary to enter a complete and detailed medical history, 
examination, and all relevant special investigations (in nit-picking 
detail) in about 3-8 minutes, and then generates a complete report in 
good English. She selects from a few of several hundred menus. The 
whole thing is under 200k. I tried several of the commercially 
available databases, and found them to be dreadful. I was tinkering 
with C at the time, but eventually wrote it in my own language, and 
it runs very well on an 8086 at 4MHz.

2. Coming up to scratch. Just my personal opinion - that no current 
languages that I have (in my incredibly limited experience) come 
across are worth a rats arse! I'm sure I stand alone in this view, 
but, that's life! You presumably know of the perfect language.

3. I was not aware that Frenchmen fuck loudly all the time. Thanks 
for enlightening me.

4. But seriously, I was referring to the tendency of the underlying 
O/S interfering with one's attempts to get something that works, or 
being so badly designed that all your attempts are thwarted. Simple 
irritations like int 14h in DOS, certain EMM's ..
>   More seriously, I believe serious work *can* be done in Lisp (next
> time you try to imply the opposite, I flame you!).

The ideas behind Lisp are great. When I played around with it about 
10 years ago, the implementations were _shit_! I'm sure they have 
improved. You can do very serious work in Lisp, provided you have 
a very fast, powerful machine with lots of memory. But would you (for 
example) choose to write a DTP package in Lisp? If you can tell me of 
a reasonably priced Lisp package that will run well on my little 386 
with 2 meg of memory, I'd love to try it again!

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

Well, I was arguing by analogy (always dangerous, and often pretty 
pointless). BUT
1. I do think there is some validity in the analogy.
2. I was more concerned about the information storage/encoding than 
the "hardware" aspect. ie. the information stored in a codon is 
analogous to the information stored on a hard disk (or wherever), I 
couldn't give a damn about the magnetic medium, adenine/guanine etc!
4 different bases grouped in threes (what could be simpler) code for 
about 20 AA's, which go to make up an infinite variety of enzymes, 
structural proteins , whatever, which go to make up "cells". A few 
simple ASM instructions go to make up (let's say) about 100 primitive 
verbs etc, which make an infinite variety of "constructs" which go to 
make up "objects". I _like_ the analogy!

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

I think you should read my letter again. I think you missed the point 
completely.


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

Hey, hey, hey. 
You say the thing's impossible, and then immediately insist on added 
complications! This is self-fulfilling prophecy, if ever I saw it!
The whole point is that it's a _symbolic_ assembler, NOT specific to 
an actual machine. Sure, you'll get a performance hit on a PDP-11. I 
believe it will however run!

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

I do not see that the memory model has to be flat. Please explain. 
Include code. 


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

You misread. I was not setting a gold standard. I was helping you to 
understand what followed. (that 80000000 is in hex).



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

As I intimated, there is no bias. A convenience. Re-read my letter.

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

It's all very well for you in your theoretical ivory tower. If I had 
an infinite number of registers at my beck & call, I might agree. 
Fortunately, I work in the real world. I use memory. I use registers.

>  [follows the list of all instructions, and an operationally-
oriented
> very informal explanation.  Nothing is defined.  After that, we get 


Ah you got that. I wrote you a sketch. Note. A sketch. Obviously what 
you wanted was a complete OS. Forgive me.


> exaple of compilation techniques worthy of the first weeks of an
            ^^^^^^^^^^^
           I suspect you read through the code _very_ quickly. I 
wrote (or at least I think I wrote) a sketch of a very simple 
**interpreter**. Fix this in your mind.         
                
> undergrad course.  Follows a more interesting section on the 
[no comment]


> > 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
                                                          ^^^^^^^^^
And now it's an assembler. The word to focus on is **interpreter**
The other word that might help you is **sketch**.     
                                                     
>   I just hope I did not sound to much like flaming.  If I did, 
No, in the sense that Milford Sound is surrounded by small hillocks.


> forgive me, and remember that English is a (very) foreign language 
You're managing just fine! What I really would like is, however, some 
_code_.



>   Merry Christmas!

And to you too, sir!


Bye, JVS.< 


P.S. On the left, as you sail out of Milford Sound, you will see a 
5600 foot granite cliff. The right side is pretty impressive, too.<