No Subject

[jfox@xxxxxxxxxx (Jeff Fox)]

>
>  What currently is unclear to me, is how the bit interleaving really works
>  and how it works in conjunction with the complementary polarity scheme.
>
>  Where are bits interleaved and toggled. In data? In adresses? 
>  What about branch targets.

1. instruction bits are interleaved.
   logical 000001111122222333333 -> 01010101012233232323 interleaved
                                              ^^^^ note irregularity
   this is a trivial thing to Chuck's assembler
   Instructions are represented in the assembler as 20 bits, and the
   5 bits in the slot you want is selected with a mask.  A  mask of
   F8000 would select the first slot in a logical model, and a mask
   of AA800 would actually mask in the instruction bits for the first
   slot for a real chip.

2. All data and address must be XORed with AAAAA as seen from the 
   the PC software view.
3. The 10 bit address used in jump and  call instructions must be
   XORed with 155 as seen from the PC view.

This is the way it appears when doing cross development on a PC.

>
>  I would very much appreciate an up to date explanation...
>
>Greetings,
>     Ulrich
>
>Ulrich Hoffmann, Uni Kiel        WWW: http://www.informatik.uni-kiel.de/~uho/
>Institut f. Informatik,                     email: uho@informatik.uni-kiel.de
>Preusserstr 1-9, D-24105 Kiel, Germany      Tel: +49 431 560426   Fax: 566143


Oh boy, one of my favorite subject. :-) I have argued about this with
Chuck on several occasions.  You see it all depends on your view so it
can get very confusing, and we have all gone around in lots of mental
circles dealing with it.

S21 does not simulate either instruction bit interleaving or the
complementary polarity bus scheme.  It was written before these features
evolved in the hardware, so the simulator remains in sync with the
"conceptual" model of the chip.  (by the way instruction bit interleaving
will go away, but the complementary polarity bus will remain on F21)

All of my tools have been designed to generate code for either the
simulator or the actual chip.  I could have changed the simulator,
but the simple conceptual model still seems easier to deal with.

It is not really very complicated unless you get caught in a mental loop.

Chuck's software is all written from the "pattern" view.  That is he
sees the 1s and 0s as they appear as voltage on the bus. FFFFF means
a pattern of all 5V.  His software XORS patterns with AAAAA to get
numbers.  SO his cross assembler XORS a number ( a double in FPC) with
AAAAA to represent it as a number or address in MuP21 memory space.
The confusion comes from the fact that he represents the opcodes
from a different view because of his way of seeing them as hardware.

From some of the things Chuck has said in public some people have
gotten very strange ideas that on MuP21 you must always think
about if something is a number or a pattern, and that the logical
instructions work on patterns and the math works on numbers and that
you have to convert with AAAAA XOR in between etc.  This is true when
you are CROSS DEVELOPING for MuP21, but it is pretty much invisible
on the chip isself.

It can get confusing when you are writting software on the PC that will
will run on MuP21 and deal with opcodes there...  So it is easy to 
get caught in a mental loop when trying do design assemblers and 
compilers in the cross development arena.  Each time you shift
mental viewpoint from the way the stuff will look to MuP21 when
it is running, and the way it will look while still on the 
PC can get confusing.  If you AAAAA XOR twice it goes away,
but if you do it again it comes back.

In P21Forth there is a version of Chuck's assembler.  Except the
opcodes are xored with AAAAA because P21 SEES from its own  bus 
representation.  To P21 a number is just a number, and only 
when you deal with i/o to non-complementary-polarity-bus machines
do you deal with patterns.  So in P21Fort the  word for IN or OUT
on the parallel port includes AA XOR.  

If MuP21 outputs 00 to an 8 bit  port it would appear as AA because
MuP21 represents bits on the bus in this complementary way.  To
MuP21 a 0 is a 0.  But if it wants to send a physical 0 to the
outside world (that does not see it from the AAAAA physical=0logical)
it must XOR it with AAAAA.

This is an issue when doing cross development.  If you compile or
assemble on a PC then all data and address for MuP21 must have the
AAAAA XOR relationship between the way MuP21 and the PC will see it.

So a literal 0 is AAAAA physically in the PC.  And the MuP21 address 0
is represented as AAAAA on the PC.

Jump and Call instructions take 10 bit arguments.  These 10 bits
must be xord with 155 when doing cross development. 

It really is not very complicated, but it can get confusing.
If you are not doing cross development you don't have to think
about it except for writing your own i/o routines.  If your
doing cross development then you are ready for such things.

The boot code is also confusing.  As a result I don't think about
these things very often.  I understand it, but I don't think about
it unless I need to work on modifying the boot code or testing 
cross development tools.

Jeff Fox