Re: Nibz processor @ <570 MAXII LEs (16 bit generic specified), 20MHz

On 14 Mar, 20:28, Walter Banks <wal...@bytecraft.com> wrote:
> Jacko wrote:
> > Feel free to make a BSD 1 bit version of nibz. It may be smaller, but
> > will take 16 times as long to execute any code, yet will be bigger
> > than 1/16th the size. Therefore the computational use density
> > (instructions per cycle per area (m^2.s)^-1) will decrease. If
> > resources are really tight to maintain budget, and the lower execution
> > speed is not relevant for the task, then maybe the power efficiency
> > implications of computational use density (CUD) are not important
> > either.
>
> A very first order metric. I am not arguing for bit serial processors
> but the 16 to 1 makes an assumption that the bit serial is only
> implementing a 16 bit data path. A well designed bit serial instruction
> set would change the metrics on both the hardware and the
> performance.

Yes, this is true of any new metric idea. The general wanted measure
is to get bigger if less standing logic (not used in a cycle) exists.
It also should encompass motion forward through a piece of code, and a
lower area for function. Higher order versions of the metric should
include the amount of instruction RAM/ROM area to perform a particular
task, as this memory also contributes to the micro-watt per unit of
computation.

I do not think nibz is a perfect thing, but it comes from a lot of
hours spent thinking, this is one of the main reasons for zero
instruction overheads (in code size) of the design. As soon as the
base routine set is defined at 4 bits per instruction. The high zero's
exist only if the designer does not choose a different start vector
(0) or does not place the nibble RAM/ROM in a convienient place.

> You are correct that control overhead does not scale but
> bit serial processors can have a bunch of viable applications
> which has been my point. Low pin count to memory and I/O
> for example. The SDcard gives multiple gigabytes of memory
> with a few pins.

Yes they do have applications with low metal/interconnect track
designs. A direct sd card interface with <= 2gb and sector size of 1
word (2 bytes or 4 bytes) would be useful for all small applications.
To solidify this circuit to a particular processor destroys a lot of
its utility.

4 giga nibbles, ummm, would have made the 4004 quite a beast.

cheers jacko

"Antti.Lukats@googlemail.com" wrote:
> On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:

> > > You have two operands and one result but there is only one data
> > > path to the serial memory. This means, you at least need one
> > > registers to temporary hold one of the operands and an address
> > > register to hold the address of the second operand. Mproz

> > Why do you need temporary registers?  If the memory is serial, each
> > bit can be fetched as needed. 

To fetch a bit you need the address of the bit. For two operands and
one result this makes three address registers which is more than using
a temporary register to hold one operand and only one address register
for to second operand, the result can be shifted in the temporary 
register where the operand is shifted out.


> > > As far as I remember, mproz uses about 250 two-input gates, that
> > > should fit well with 65 flip-flop's.
> >
> > How about the memory?  I expect that will be an order of magnitude
> > larger than the machine itself, even for a small program.

The size of the needed memory depends mostly on the application
and not on the CPU architecture. 



> mproz stands for minimal.. so it is minimal in terms of instructions
> and resources
> in the tradeoff of speed (8 clocks!) and program size
> 
> the machine is funny, it can do subroutine calls by patching own code
> on the fly

You don't need to patch the code (you can't patch code in ROM). You
can either use a software stack or, if the subroutine doesn't need to
be re-entrant, a fixed ram location to store the return address for
the subroutine. But indirect addressing requires self modifying
code, so you can do it only in RAM but not in ROM.

> that is self modifying code is needed, normal instructions are 6 bytes
> or 8 bytes

The jump instruction is one word (2 bytes), the add/nor instruction
4 bytes for the two address machine and 6 bytes for the three address
machine. But code density seems to be the sane for the two and three
address machine.

> if new immediate constant is needed. Also shift and rotate are very
> clumsy i guess

a left shift is simple an "add", a rotate left are three instructions:

     add   r0,r0  ; lsl r0
     br    _10    ; branch if carry not set
     add   #1,r0  ; set LSB
_10:


a rotate right is simple 15 times a rotate left.
 

> so the maximum 32K memory space would only hold say about 5K
> instructions !

The predecessor XPROZ ( http://www.bitlib.de/pub/xproz/ ) was a three
address machine with an instruction length or four 16-bit words.
A multitasking operating system with all the system utilities in a
ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard 
disk, floppy, serial and parallel port, keyboard interface and a 
graphics card.

On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> "Antti.Luk...@googlemail.com" wrote:
> > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > > You have two operands and one result but there is only one data
> > > > path to the serial memory. This means, you at least need one
> > > > registers to temporary hold one of the operands and an address
> > > > register to hold the address of the second operand. Mproz
> > > Why do you need temporary registers? =A0If the memory is serial, each
> > > bit can be fetched as needed.
>
> To fetch a bit you need the address of the bit. For two operands and
> one result this makes three address registers which is more than using
> a temporary register to hold one operand and only one address register
> for to second operand, the result can be shifted in the temporary
> register where the operand is shifted out.

Are you saying that the mproz has all these hidden registers?  How is
that different for a serial version?  The serial version should be
able to fetch one bit of each operand and write one bit of the
result.  I don't know how the machine works in detail.  I didn't see
anything that would explain this clearly.  So I can't really say how
this could work better (smaller actually) as a bit serial machine.


> > > > As far as I remember, mproz uses about 250 two-input gates, that
> > > > should fit well with 65 flip-flop's.
>
> > > How about the memory? =A0I expect that will be an order of magnitude
> > > larger than the machine itself, even for a small program.
>
> The size of the needed memory depends mostly on the application
> and not on the CPU architecture.

That is a non-sequitur.  This machine is *very* inefficient in its use
of memory.  The memory is also a resource.  If the application does
not require any more memory than the size of the machine, it is very
unlikely that this would be smaller than a simple FSM!

I think I've lost the idea of what we are discussing here.  The
original premise was that a parallel machine can be designed with a
bit serial data path and save resources.  I supposed you can always
find some odd architecture where this is not true, but I would say it
should at least be a practical one.


> > mproz stands for minimal.. so it is minimal in terms of instructions
> > and resources
> > in the tradeoff of speed (8 clocks!) and program size
>
> > the machine is funny, it can do subroutine calls by patching own code
> > on the fly
>
> You don't need to patch the code (you can't patch code in ROM). You
> can either use a software stack or, if the subroutine doesn't need to
> be re-entrant, a fixed ram location to store the return address for
> the subroutine. But indirect addressing requires self modifying
> code, so you can do it only in RAM but not in ROM.
>
> > that is self modifying code is needed, normal instructions are 6 bytes
> > or 8 bytes
>
> The jump instruction is one word (2 bytes), the add/nor instruction
> 4 bytes for the two address machine and 6 bytes for the three address
> machine. But code density seems to be the sane for the two and three
> address machine.
>
> > if new immediate constant is needed. Also shift and rotate are very
> > clumsy i guess
>
> a left shift is simple an "add", a rotate left are three instructions:
>
> =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0
> =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set
> =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB
> _10:
>
> a rotate right is simple 15 times a rotate left.
>
> > so the maximum 32K memory space would only hold say about 5K
> > instructions !
>
> The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> address machine with an instruction length or four 16-bit words.
> A multitasking operating system with all the system utilities in a
> ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> disk, floppy, serial and parallel port, keyboard interface and a
> graphics card.

That sounds right.  Normal CPUs can host an RTOS in around 10k to 16k
bytes, no?

Did the mproz have a purpose?  Is there anything it is especially good
at in a practical way?

Rick

On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
>
> > "Antti.Luk...@googlemail.com" wrote:
> > > On Mar 14, 8:49 pm, rickman <gnu...@gmail.com> wrote:
> > > > On Mar 14, 11:11 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > > > You have two operands and one result but there is only one data
> > > > > path to the serial memory. This means, you at least need one
> > > > > registers to temporary hold one of the operands and an address
> > > > > register to hold the address of the second operand. Mproz
> > > > Why do you need temporary registers? =A0If the memory is serial, ea=
ch
> > > > bit can be fetched as needed.
>
> > To fetch a bit you need the address of the bit. For two operands and
> > one result this makes three address registers which is more than using
> > a temporary register to hold one operand and only one address register
> > for to second operand, the result can be shifted in the temporary
> > register where the operand is shifted out.
>
> Are you saying that the mproz has all these hidden registers? =A0How is
> that different for a serial version? =A0The serial version should be
> able to fetch one bit of each operand and write one bit of the
> result. =A0I don't know how the machine works in detail. =A0I didn't see
> anything that would explain this clearly. =A0So I can't really say how
> this could work better (smaller actually) as a bit serial machine.
>
> > > > > As far as I remember, mproz uses about 250 two-input gates, that
> > > > > should fit well with 65 flip-flop's.
>
> > > > How about the memory? =A0I expect that will be an order of magnitud=
e
> > > > larger than the machine itself, even for a small program.
>
> > The size of the needed memory depends mostly on the application
> > and not on the CPU architecture.
>
> That is a non-sequitur. =A0This machine is *very* inefficient in its use
> of memory. =A0The memory is also a resource. =A0If the application does
> not require any more memory than the size of the machine, it is very
> unlikely that this would be smaller than a simple FSM!
>
> I think I've lost the idea of what we are discussing here. =A0The
> original premise was that a parallel machine can be designed with a
> bit serial data path and save resources. =A0I supposed you can always
> find some odd architecture where this is not true, but I would say it
> should at least be a practical one.
>
>
>
> > > mproz stands for minimal.. so it is minimal in terms of instructions
> > > and resources
> > > in the tradeoff of speed (8 clocks!) and program size
>
> > > the machine is funny, it can do subroutine calls by patching own code
> > > on the fly
>
> > You don't need to patch the code (you can't patch code in ROM). You
> > can either use a software stack or, if the subroutine doesn't need to
> > be re-entrant, a fixed ram location to store the return address for
> > the subroutine. But indirect addressing requires self modifying
> > code, so you can do it only in RAM but not in ROM.
>
> > > that is self modifying code is needed, normal instructions are 6 byte=
s
> > > or 8 bytes
>
> > The jump instruction is one word (2 bytes), the add/nor instruction
> > 4 bytes for the two address machine and 6 bytes for the three address
> > machine. But code density seems to be the sane for the two and three
> > address machine.
>
> > > if new immediate constant is needed. Also shift and rotate are very
> > > clumsy i guess
>
> > a left shift is simple an "add", a rotate left are three instructions:
>
> > =A0 =A0 =A0add =A0 r0,r0 =A0; lsl r0
> > =A0 =A0 =A0br =A0 =A0_10 =A0 =A0; branch if carry not set
> > =A0 =A0 =A0add =A0 #1,r0 =A0; set LSB
> > _10:
>
> > a rotate right is simple 15 times a rotate left.
>
> > > so the maximum 32K memory space would only hold say about 5K
> > > instructions !
>
> > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> > address machine with an instruction length or four 16-bit words.
> > A multitasking operating system with all the system utilities in a
> > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> > disk, floppy, serial and parallel port, keyboard interface and a
> > graphics card.
>
> That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k
> bytes, no?
>
> Did the mproz have a purpose? =A0Is there anything it is especially good
> at in a practical way?
>
> Rick

Rick,

there is. a practical reason to use.
that is why i did convert the ISE SCH to plain VHDL

unfortunatly my notebook HDD had a bad BOD crash
stopping on CRCDISK.SYS
(pevious notebook was replaced because of similar error!)

so i am doing backups at the moment,

but yes
mproz was developed for XC2K and was great
for that architecture, at the times when 64K
was about maximum of RAM or EEPROM
available for educational institutions

Antti

On Mar 15, 2:40=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 15, 5:53=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 14, 9:16=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > The predecessor XPROZ (http://www.bitlib.de/pub/xproz/) was a three
> > > address machine with an instruction length or four 16-bit words.
> > > A multitasking operating system with all the system utilities in a
> > > ROM-disk still fitted in 64 kbyte ROM. The OS had drivers for a hard
> > > disk, floppy, serial and parallel port, keyboard interface and a
> > > graphics card.
>
> > That sounds right. =A0Normal CPUs can host an RTOS in around 10k to 16k
> > bytes, no?
>
> > Did the mproz have a purpose? =A0Is there anything it is especially goo=
d
> > at in a practical way?
>
> > Rick
>
> Rick,
>
> there is. a practical reason to use.
> that is why i did convert the ISE SCH to plain VHDL
>
> unfortunatly my notebook HDD had a bad BOD crash
> stopping on CRCDISK.SYS
> (pevious notebook was replaced because of similar error!)
>
> so i am doing backups at the moment,
>
> but yes
> mproz was developed for XC2K and was great
> for that architecture, at the times when 64K
> was about maximum of RAM or EEPROM
> available for educational institutions

Ok, so this is a design for a 20 year old chip family?  Why is it
interesting today other than for historical context?

Rick