[LispM-Hackers] First Function

[James A. Crippen]

"Dave Richards" <dave@synergy.org> writes:

> (f) Afrter disp= we should add a friend like (0x0000) showing which
> INSN is the actual target of the branch.  It would make it a bit
> easier to read.

I just looked at doing this, but the thing keeping track of
instruction offsets is a loop counter above the actual dump of the
instruction.  It would necessitate passing some data to the dump
method or storing that data somewhere.  I haven't looked at this code
in a while (honestly I haven't looked at E3 in over a month) so I
don't know off the top of my head whether this would be easy or not.

I think the fix would be that the instr.dump() call at line 1804 in
memobj.cc (inside memFEFHeader::dump()) would need to be handed the
'i' variable that's the counter for the surrounding loop.  This would
mean that e3MacroInstruction::dump() in macroop.cc (at line 84) would
need to maybe take an e3u32 argument for what offset the instruction
is currently at.  That's one way of doing it, anyway.  Any other
ideas?

> Is there any place where the registers of the processor are defined?
> I don't mean the micro-registers, I mean the macro ones.  We know
> that registers must exist for the stack pointer, location counter,
> current function.  There must also be some environment registers,
> etc.  Has anyone seen a list of these?  I have not checked the stack
> groups section yet, they're probably in there.

Look on page 11-7 of the SSDN2:

                         C's state is not shown, because it  is  in
  the   five  registers  M-CALL-INFO,  M-ARGUMENT-POINTER, M-LOCAL-
  POINTER, M-FEF, and LOCATION-COUNTER.  The values of  M-ARGUMENT-
  POINTER  and  M-LOCAL-POINTER are indicated in Figure 11-1 by the
  two  arrows  marked   "argument-pointer"   and   "local-pointer."
  LOCATION-COUNTER    is    described    in    the    section    on
  Macroinstructions; note that when the registers are pushed on the
  stack, its offset from the beginning of  the  function  is  saved
  instead.

All of these are presumably the registers you're thinking of.  They
don't exist in E3 because nobody's put them in yet, and nobody's
thought of a good way to structure them yet either.  Presumably a CPU
register class needs to be spun up and some container should be
created to hold the relevant number of registers.  Or maybe something
else?

Much of the stuff in SGs seems to me to be microcode related.
Particularly the SavedMFlags, the SGACs (perhaps), etc.

Basically E3 is right now more of a tool for investigating the band.
Not all the machinery necessary to make it useful for being a
processor (eg, keeping state, modifying memory) is in place.  It's not
been thought out yet because we didn't know what we would need yet.
Things like the necessary registers to implement are just now becoming
clear (to me anyway).

\begin{rant}
It doesn't help that I'm spending a lot of my time looking for work so
I can keep paying my rent.  Nor that I'm trying hard to get Japanese
CID-keyed fonts working in XF86 4.2.0 so I can get some Japanese input
stuff going (I'm learning Japanese on the side).  JM and I are both
thrashing for entirely different reasons (most of his are legitimate,
most of mine are not).  It's hard to keep all the data about E3
swapped in my brain and I've been fairly distracted lately.

But then again, this project has had fairly glacial progress from the
beginning.  That's what you get I suppose when you try to emulate
hardware for which you don't have much documentation or even a working
example to test against...  Foo.  It's not stopped us yet though.
Damn futility!
\end{rant}

I should probably go to bed.  I'll look into filling in the miscop
printers tomorrow.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.