(?) Themes

[Johan Van Schalkwyk]

This is a fairly long document, with three themes.

Theme 1.
========

Organisation. If we don't get this right, we might as well pack up and
go home. I've seen a _great_ number of really good ideas in the past
few days, and I imagine things will settle down but at present I have
difficulty in keeping up with all the suggestions and counter-suggestions.
Many of them seem to be saying the same / similar things in different
words! The idea of having different subject groups with different editors
seems good to me. I would like to take it a bit further:-

Is it not possible for someone originating a new idea/section to send,
as the first part of the title, the following:


  (?)


Let the TUNES@ENS.FR mailer identify this as being a request for a new
theme, stamp it with the next number in sequence, AND THEN PASS IT ON
TO EVERYONE. (1) would be the first ever theme, (2) the second, and so on..

Extending this idea, one could reply to e.g. thread number (3) with the
message: 3()  in the header, and our reply would be stamped with the number
3(7) - if it were the seventh reply - before being re-mailed to everyone.
This approach would:-

a. Clearly delineate who preceded whom:
		-- 3(6) precedes 3(7)..
b. Enable immediate identification of various threads:
		-- eg thread 1 might be low level language ideas ..
c. Tell you if you're missing items in the sequence:
		-- this is 7(23). Whatever happened to 7(21) and 7(22)?
d. Be useful in assessing who is active, which threads are being used:
		-- currently active threads are 1, 3, 17, 4 etc.
e. Be useful in requesting back copies / archives:
		-- please send me 1(7), 23(184) etc.


The idea could even be extended to sub-threads for a lovely branching tree
structure: for example, IF thread (1) is "low level language" and you want
to create & control the compiler section, you might send a message with
the title:-

(1?) LLL : Compiler Section - Moderator Joe Bloggs

and the TUNES@ENS.FR mailer responds by stamping your message with:

(1.1) Compiler Section - Moderator Joe Bloggs

 -- or, if (1.1) already exists, then (1.2) and so on.

1.1 Is this feasible?
---------------------
1.2 What does everyone think of this?
-------------------------------------
1.3 If someone has a better idea, please say so!
------------------------------------------------





Theme 2.
========

Low level language/constructs.

People are talking about "microkernels" &c. There seems to be a considerable
amount of dissent about what we need, how big it should be, what it should
contain, etc. I would like to make several points:

Point 1.
--------
Let us not be bound by convention. Too often, I find my thinking being
channelled by what people have regarded as the "norm". I really believe that
if we make a cock up of the lower level(s), the whole cannot possibly work
well. Too many times in the past, I have tried to work on higher levels and
been crippled by low-level design flaws. (This may be the reason why I'm
unashamedly an assembler hacker)!

Point 2.
--------
If we make our lower level too vague and nebulous it will not work. 
Conversely, if we make it too rock-hard and specific, it will be
overwhelmed by progress. We need to find a compromise.

Point 3.
--------
I would (humbly) suggest that in defining our low level "constructs" we
use the following idea, that I call "impedance matching". Please feel free
to flame away, I suspect that most of you are more hot-shot programmers
than I am (perhaps by an order of magnitude), but here it is for what
it's worth:-

If, for example, you're connecting up your hi-fi speakers to your amp,
it makes sense to match the output impedance of the amp to the (nominal)
impedance of the speakers. Can we not use a similar (albeit much more
generalised) approach in interfacing our higher level programming with
the "machine level"? That is, define your "software constructs" so that
they match up to "what's on the other end of the line"! Let me give an
example. Rather than having an extremely complex set of commands etc
for managing a variety of video displays, rather ask the question "What
is the purpose of a VDU and what do we want out of it?". Look at this
very carefully in terms of the properties of the intended target (the
human eye+brain : the two are not readily divisible) - I didn't say it
would be easy - refine your requirements to a basic set of properties
eg minimum angular resolution.. maximum pixel size that won't  give the
average person a headache [try staring at a blurry CGA screen for 8 hours],
extract a basic set of requirements, refine this (eg specify minimum
and ideal conditions), examine this in terms of (a) currently available
hardware/software, and (b) what might reasonably be expected to occur
in the next n years over which the project will extend, and finally
decide on a few simple low-level "constructs" that will be easy to
work with and meet our requirements. If a particular system cannot
meet the requirements, create constructs that approximate them as
best possible. Work through numerous examples to test your constructs.

This may sound (a) like hard work and (b) very vague, but I'm more trying
to convey a general concept than preach about SVGA standards, or 
neurobiology.


Point 4.
--------
Define a "minimum level" at which the buck stops: this is the level of
machine independence. I think that in-line code above this level is an
atrocity which should NOT be permitted under any circumstances (whatever,
until hell freezes over ..).

Call this what you want - a "microkernel level" or a 
"symbolic assembly language level" (which is a term which I considered
but rejected as being too restrictive). I (in correspondence with a few of
the chaps) have simply referred to this as "level 1". EVERYTHING above 
(at no matter how high a level of abstraction etc) is "level 2", EVERYTHING
below, be it machine code, hardware devices etc, is "level 0". 

I have been playing around with this concept a bit, and have a few
very basic ideas about what simple constructs could be used in various
circumstances. This needs a lot of work.


Point 5.
--------
Cut out the crap.

Especially on "level 1". This should be lean, clean and mean. NO
unnecessary constructs that can be represented on a higher level, or
using simple combinations of more primitive constructs.

I think that it is here very important to identify those primitive
"functions" or "core components" that should be the effective working
vocabulary of level 1. 


Point 6.
--------
Have optimization facilities. Your level 1 code may be something along the
lines of:

	MOV	R0,[R1]
	INC	R1

and, depending on the machine this may be "optimised" to 

	CLD
	LODSD

or

	MOV	EAX,ES:[EDI]
	INC	EDI

or whatever. But the level 1 code is still kept as a generic
	MOV	R0,[R1]
	INC	R1


This (I think) resolves some of the argument that has been, well, raging
is perhaps too strong a word, about multiple representations of code.
The original code is there. The (smart) optimiser jacks it up on request
for a particular machine, and (if you really wish) you can descend to
symbolic level 0 and examine the machine-specific representation. But on
level 1, all you get is good old vanilla
	MOV	R0,[R1]
	INC	R1


[[Please note that I am not implying any sort of intel-type notation, or
specific register names, this is just for the sake of demonstration,
nomenclature is for later]]!


Point 7.
--------
Have a generalised and non-cramped way of representing parallel structures.
To my mind (again, flame away, he cried in paranoid agitation), any sort
of fork/join construct that is to be legible should have some sort of
two (or even three??) dimensional structure: ie.

			begin
			  |
			  |
	*****************fork********************
	*					*
	part(1)					part(2)
	*					*
	*****************join********************
			  |
			etc.

rather than some sort of:
	fork:
	  begin part(1)
	  wait_for part(2)
	  end
	  begin part(2)
	  wait_for part(1)
	  end
	end_fork			or whatever.

I would ideally incorporate this form of representation into ALL level 1
coding, ie. have all code broken down into parallel constructs WHEREVER
THIS IS POSSIBLE. This is for two main reasons:
	a. To facilitate use in a parallel environment (even if it's just
		the two pipes of a Pentium)!
	b. To demonstrate to the programmer where parallel constructs
		are possible, and to hint at better optimisation techniques;

Show it. You don't have to USE it.


Point 8.
--------
Have indications of timing for all level 1 constructs available on request
for a particular machine (eg. minimum execution time, maximum execution time,
and perhaps average expected execution time). Have guaranteed delay
mechanisms too.



OK, these were just a few basic ideas about a "low level language".

2.1 I would welcome specific comments!
--------------------------------------




Theme 3.
========
Higher level constructs.

I have actually constructed a working language that embodies at least
some of the concepts that have been bandied about (without being OO,
however). It is stack-based, vaguely Lisp-like (without the Lots of 
Irritating Single Parentheses), written in 8086 (in ... euugh .. a
DOS environment), atomic, friendly & interactive, moves like a small
demon even though interpreted, and can easily be incrementally compiled.


3.1 I will bore you with the details if you specifically request them.
----------------------------------------------------------------------


Bye, JVS.