Shoes. ships. sealing wax. Mooses?

[Johan Van Schalkwyk]

Dear Francois-Rene

>To me, this means a hardware abstraction layer must provide abstraction for
>all those kind of bit operations, where C (for instance) only provides ands,
>ors, xors, and shifts. Being able to do this directly on registers also means
>this hardware abstraction layer should still allow hardware access when needed
>(much like _AX statements in turbo pascal).

Agreed. My idea would be to use "primitive" operators, and have everything
very carefully delineated, with resolution into components as if everything
were parallel, eg. silly code like...

PUSH R0
MOV R3,&00002345
SHL R0,1
SHL R0,1
ADD R0,R2
MOV R1,SEG01:[R0]
INC R3
POP R0
JZ  WHEREVER

might become something like:-

					|
	**(1)*************************(fork)*****************(2)*
	*							*
	|						PUSH	R0
	MOV	R3,&00002345				SHL	R0,1
	INC	R3					SHL	R0,1
	|						ADD	R0,R2
	|						MOV	R1,SEG1:[R0]
	|						POP	R0
	wait for (2)					wait for (1)
	*							*
	******************************(join)*********************
					|
				JMP	WHEREVER

and then the intelligent programmer's apprentice (program) will point out
that the left side resolves to MOV R3,00002346 / JMP.. and also implement the
right hand side as MOV ECX,DS:[EAX][EBX*4] on a 386, but perhaps in some
totally different way with another processor (but the source will be stored
as primitives, with relevant notes about different system implementations,
if desired)! Obviously, a lot of work is needed in deciding what primitives
are appropriate in a general context!


...BUT I would only allow this to occur on my hypothetical level 1. 
If you are programming on a higher (symbolic) level 2 and are unhappy with
eg speed considerations, you will not simply insert inline code there
(even non-processor specific symbolic code), but you will have to formally
employ a "function" of some type, and then go down one level to the symbolic
assembly level 1 and define this "function" (or whatever) in terms of 
primitive constructs. (Do you think this is workable? Is it too 
restrictive?)

I also like the idea of having all the core software written in such code,
so that it can optimise itself. It also raises the possibility that (with
a bit of judicious help) such a program could even be implemented in a
higher level language, and then "tunnel down" to a lower level by analysing
it's own code and optimising itself! (The amount of "self knowledge"
implicit in this, especially in respect of timing, is of course quite
intimidating)!


>I've never ever seen any commercial software with good semantics, and syntax
>was even more horrible.

Yeah, well, okay, perhaps (for the sake of argument) I was being too kind!


>But these last months have been working with a purely syntactic system,
>which had no designed semantics, and where features had been added and added

My sympathy.


> (if you read french, I'll send you my masters report).

Apologies. Lazy slob does not read French (yet). 


>So what I say is you shouldn't add syntactic features on the fly without
>studying the semantical effects, and that things that appear syntactically
>simple are unusable semantical monsters (like this B stuff I've been working
>with). Not to say that what YOU wrote is such (I do not know it very well,
>and it did not look that way to me).
I agree absolutely. Some (many) of my ideas may be completely unworkable.
But one can only try. I think that half the problem is with ivory tower
academics who have never sat down and written twenty thousand lines of
worthwhile code in their lives!


>Well, yes and no: to me, the level 0 (hardware dependency) is very limited,
>and expands very slowly. Level 2 (human interface) we have little control on
>it, and it's not the algorithmically interesting part of a program; let it
>be automatically generated when possible. Level 1 (the algorithmic part of
>the software) is infinite, and contains an infinite partially ordered only
>hierarchy of sublevels.

I'm not sure that it's necessarily true to say that he hardware expands that
slowly. cf what we had ten years ago. Also, the software most regrettably
seems to lag several years behind the hardware!? Also, I see level 1 as
a fairly well-defined boundary separating the highly abstract level 2 from
the "hardware like" level 0 (ideally all hardware, but often necessarily
containing large software constructs). But I think that perhaps we should
get down to brass tacks, rather than philosophising for ever!


>> Q3. Have you thought about legible constructs for _parallel_ architectures?
>Yes. first thing: do not use global variables when possible, so that
>distribution be as simple as possible (without some global thread being
>ever accessed). 
Yep. But it depends what you mean by "global". I certainly agree that almost
all variables must be restricted in their scope, but on the other hand, one
should avoid excessive shuttling of parameters to and fro _within_ the
context of (a sometimes quite large) module, just because one is obsessed
with keeping everything "local"!


>Then a generic FOR construct with a variable taking all values
>in a set, and a recursive FOR construct to use recursively defined structures,
>will provide distribution.
Surely this "FOR" is a specific instance, and not general enough?
How how would you, for example, represent code that searches for a
particular text sequence in a long character string, given that you want
near-optimal searching AND that you do not know whether the machine you
are implementing the search on may be either sequential or parallel? I
for one would have to do a hell of a lot more reading about parallel
architectures before I was even vaguely confident that I could answer
the question, and, even more importantly, create a general architecture
that implements the answer for this and similar cases. (Altho I have
a few ideas)! Is linear searching such a basic operation that one should
have a SEARCH operation as a primitive on level 1, or should you leave it
for the user to define in terms of level 1 primitives, or should the
user even define this on a higher level?? I think that questions such
as this are valid if one is to design a workable system, and indeed, we
will probably have to ask many such questions. 


>If you're designing an new chip, that sounds ok. But if you're writing a
>computing system on existing architectures, then I think it's too late to
>correct the asm.

What I meant was, that the "symbolic assembler" of level 1 can (with
a lot of careful thought) be a lot more friendly than many current 
assemblers. (You might argue that it would be more a compiler than an
assembler, but I would have a lot of trouble applying the term "compiler"
to something that is on the one hand putting together something that
almost looks like microcode into assembler instructions, and on the other
implementing "calls" to complex level 0 constructs that may be either
hardware defined or written in assembler)! Anyway, what's in a name?


>Ok. I'll mail you as soon as I've gathered the team.

Great. You may find that my level of expertise is not adequate to your
task, but I'm prepared to give it a good tonk!! I'm sure we can look
forward to some good fights!


Bye for now, JVS.