Various subjects [far36]

[Gary D. Duzan]

In Message <9306242044.AA18630@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>(A-)Synchronousness
=>-------------------

   I don't know anything about Occam, but I would go for including
both as well, though the interface should allow for the case where
one is emulated in terms of the other.

=>Linking objects
=>---------------
=> Info objects must contain:
=>
=>Code:
=>- what are the implicit or explicit parameters; what is read,
=>and what is changed.
=>- How it changes data.
=>- What other code is called; what other code calls me.
=>
   I'm not sure I take your meaning. Parameters can be expressed
explicitly enough, but not the semantics of the code. Are you wanting
to attach human-readable notes on the semantics to objects?

=>Data:
=>- who can read and who can write.

   So what is a "who"?

=>- What other data is pointed at; what other data points at me.
=>
   The former is no problem, but if I understand you correctly, the
latter is essentially the GC problem discussed later.

=>Garbage Collecting
=>------------------

   Right, no GC among system objects. GC within system objects
optional.

=>Demand paging & scheduling
=>--------------------------
=>
   Do you want automatic (profiled?) or programmer-defined preloading?

=>MUSIC
=>-----
=>
   No mention of X? As I'm not much of a UI person, I'l not comment
further.

=>Let's begin Coding
=>------------------
=>
=>* There seems nobody has anything fundamental to add about specs.

   What specs?

=>* languages used. For device programming, let's use ANSI C and
=>Assembly (I vote for TASM, but perhaps you'll prefer GAS).
=>TASM has got good macros et al. and uses standard Intel pseudo-code.
=>GAS seems to have good macros, but uses non-standard pseudo-code for
=>intel instructions.

   GAS is free and portable; I doubt that TASM is either.

=>The language team (including myself) will build a C to HLL compiler, and
=>an assembler into HLL embedder.
=>C code will have to include HLL directives inside comments.
=>
   Why comments? Why not pragmas or something?  Perhaps adopt the C++
'extern "C" {}' construct.  I'm reminded of C64 BASIC programs that had
assembly imbedded as a rem statement on the first line.

=>Please comment. Problem:
=>what kind of pointers to use in MOOSE implementation: near pointers, far
=>pointers or system only pointers ?
=>
   For portability reasons, inter-object pointers should be special
system pointers, interpreted by the destination objects themselves.

=>* For IO (Especially disk I/O and SuperVGA programming), we can get
=>docs from Linux and/or XFree drivers code, and other PD code.
=>
   They are at least a good source for example code. 386BSD too.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts