Zero operand CPUs

Hi,

Not sure I want to jump into this (but I couldn't resists ;-) ) but I
created a stack RISC processor back in 1990 which was targetting space
application.
It had the ADA run-time kernel in hardware and support 8 tasks in
hardware.
We handled the memory accesses using cache, there is no real
difference in cache for stack machine or register-file based CPU.
We did however had one operand to minimize the program code size.
Instead of just operating on the two operand on the stack, one operand
was address with a stack offset.
This removed tons of push instructions and thus minimized the program
code space.

A processor needs assembler, simple as that. Debugger is nice to have
but you can develop stuff without it, it just takes longer time.
C compiler is needed if you want more users.

With Xilinx 6-LUT, you can really make small 16-bit RISC machines
which is register file based.
Programming a register based CPU in assembler is much easier than a
stack machine.
I crafted a couple of years ago a 16-bit machine which could be as
small as 200 LUTs (4-LUT) but was around 300 LUTs in general.
It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
So the only benefit I see a stack machine has is more compact code.

G=F6ran Bilski

Jonathan Bromley wrote:
> On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), 
> Antti Lukats wrote:
> 
>> well assembler is GOOD if it exist :)
>> so any soft-core with assembler is ok
>> but there is no assembler for nibz? so == useless.
>> no C, no assembler, == not possible to use :(
> 
> I think you're being a bit blinkered about this.
> Writing an assembler for a machine as simple as
> nibz is not much more than a day's work if you 
> are sensible about your choice of tool (Tcl, Perl?)
> and limit your ambitions reasonably.  No rocket
> science required.

Write it in Forth.  Also about a day's work.  Use a PC Forth to generate 
code for it, and when you get it working set up a little "talker" for 
interactive debugging.  You don't need a full Forth in the target for that.

We have several times managed low-level controllers (not quite "smart" 
enough to support a full Forth VM) that way.

...
> I'd consider throwing together an assembler for
> nibz myself, but like many others here I simply
> can't divine its specification from the published
> docs - and that's my real problem with it.  If 
> jacko wants it to become more widely accepted he
> must put in the effort to document it intelligibly
> (or find someone else who can do so).  He's 
> competing in a very crowded marketplace, and 
> has erected very effective barriers to other 
> people's understanding of his offering;
> not a smart move.

Ah, well, that's a problem.  If you can't get a detailed description of 
the instruction set, you're stuck.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On 17 Mar, 17:33, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 17, 6:12=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
>
>
> > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT),
>
> > Antti Lukats wrote:
> > >well assembler is GOOD if it exist :)
> > >so any soft-core with assembler is ok
> > >but there is no assembler for nibz? so =3D=3D useless.
> > >no C, no assembler, =3D=3D not possible to use :(
>
> > I think you're being a bit blinkered about this.
> > Writing an assembler for a machine as simple as
> > nibz is not much more than a day's work if you
> > are sensible about your choice of tool (Tcl, Perl?)
> > and limit your ambitions reasonably. =A0No rocket
> > science required.
>
> > >a non working somesort of forht partially adopted
> > >but not really tested does not count as development tool.
> > >a simple assembler would.
>
> > Yes. gcc is not the only act in town for these
> > very simple, small machines. =A0A simple assembler
> > gets you going, and a nice macro-generating
> > assembler gets you productive, for very little
> > investment in the tool chain. =A0Of course a full
> > C toolchain is way better; but targeting gcc to a
> > new machine is not for the faint-hearted, I think
> > (it's not for me at all, I would have no idea
> > how to start).
>
> > I'd consider throwing together an assembler for
> > nibz myself, but like many others here I simply
> > can't divine its specification from the published
> > docs - and that's my real problem with it. =A0If
> > jacko wants it to become more widely accepted he
> > must put in the effort to document it intelligibly
> > (or find someone else who can do so). =A0He's
> > competing in a very crowded marketplace, and
> > has erected very effective barriers to other
> > people's understanding of his offering;
> > not a smart move.
> > --
> > Jonathan Bromley, Consultant
>
> > DOULOS - Developing Design Know-how
> > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > The contents of this message may contain personal views which
> > are not the views of Doulos Ltd., unless specifically stated.
>
> right Jonathan
>
> a simple assembler would suffice
> a good macro assembler is better
> or then can use c preprocessor on the asm source
> or use some retargetable assembler..
>
> but if the core specs itselfs are really fuzzy then its
> hard to use it, or make an assembler for it

There is now a link on the instruction set page presenting an english
text description of the BO instruction. All other instructions follow
a similar symbology.

SU always has carry, BO always rotates through carry. DI leaves the
carry alone, just like all the register/memory move instructions. All
opcodes above 15 are subroutine call addresses. There are no general
purpose register fields in the 4 bits of hardwired 16 opcodes (0-15),
although there is some pattern to it.

Yes the indexing has been fixed, i.e. non-clocked assignment to
indirect, which is also good for speed, as well as executing the
current instruction rather than the current operation with the last
instruction's indirection register. (this removes a row of clocked
flip-flops).

Personally I find what else I have to explain as a difficult task. I
would accept any correct documentation which falls under the BSD
licence, or has no publication restriction.

The simplicity of the assembler was the main reason for the
instruction choice, and lack of multiple addressing modes. In some
senses the assembler complexity indicates how much decode processing
is required for an instruction. There is a GPL assembler written in
forth, using the gforth sytem this is suitable for macro programming.
It's a tiny amount of code.

The lack of certain complicated instructions takes some working
around, but it is not beyond a talented code writer. The macro feature
is not really relevant, as a subroutine will work, but I suppose some
critical inline macros would be useful to some to prevent excessive
return stack juggling.

All instructions are fixed and final, except RE and SE, which are
useful only in multi-tasking, and even then there is some debate.

cheers jacko

On 17 Mar, 20:17, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> Hi,
>
> Not sure I want to jump into this (but I couldn't resists ;-) ) but I
> created a stack RISC processor back in 1990 which was targetting space
> application.
> It had the ADA run-time kernel in hardware and support 8 tasks in
> hardware.
> We handled the memory accesses using cache, there is no real
> difference in cache for stack machine or register-file based CPU.
> We did however had one operand to minimize the program code size.
> Instead of just operating on the two operand on the stack, one operand
> was address with a stack offset.
> This removed tons of push instructions and thus minimized the program
> code space.

Sounds ok. I did think of using such a pick optimization, but
considered it responsable for a potential cache slowdown as the design
progresses. In nibz picking lower in the stack like this may be
possible, but is not advised for scalability reasons. I have the idea
too that any object C (++) should have method local instance variables
only, indicating which method has write access to the variable. A
tough restriction, but I think essential for scalable future coding.

> A processor needs assembler, simple as that. Debugger is nice to have
> but you can develop stuff without it, it just takes longer time.
> C compiler is needed if you want more users.

True.

> With Xilinx 6-LUT, you can really make small 16-bit RISC machines
> which is register file based.
> Programming a register based CPU in assembler is much easier than a
> stack machine.
> I crafted a couple of years ago a 16-bit machine which could be as
> small as 200 LUTs (4-LUT) but was around 300 LUTs in general.
> It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
> So the only benefit I see a stack machine has is more compact code.

Yes , a good code density is possible. The use of code compression
techniques by using an indirect jump vector table is a possible
improvement in code density.

Thus the following memory types could be defined.
1. Microcode. 4 bit instructions wide memory.
2. Jumpcode. n bit < 16 bit (n->16 map addresses).
3. Fullwidth. 16 bit.

cheers jacko

Antti.Lukats@googlemail.com wrote:
> On Mar 17, 5:09 pm, rickman <gnu...@gmail.com> wrote:
>> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com"
>>
>>
>>
>>
>>
>> <Antti.Luk...@googlemail.com> wrote:
>>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote:
>>>> Hi
>>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>>>> Another zero operand CPUhttp://nibz.googlecode.com
>>>> cheers jacko
>>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two
>>>> conditions.
>>>> 1. A K Ring Technologies Logo must be printed atop the chip or close
>>>> by on the PCB at any resolution.
>>>> 2. Any documentation produced must acknowledge copyright and provide
>>>> the URL.
>>>> This licence is for those folks who do not like the BSD derived work
>>>> restrictions.
>>> the difference between zpu and nibz is that ZPU is supported
>>> by GCC toolchain, while there are no tools to generate any
>>> meaningful code for nibz
>>> correct me if i am wrong
>>> Antti
>> Is that really the primary critera?  I think you are right.  But I
>> have a similar CPU design that I expect to use on a project shortly
>> and it will be programmed in assembly, but it will look a lot like
>> Forth.  I consider that to be close enough to a high level language.
>>
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful?  There aren't many projects done in C that are debugged
>> without an emulator.
>>
>> Rick- Hide quoted text -
>>
>> - Show quoted text -
> 
> well assembler is GOOD if it exist :)
> 
> so any soft-core with assembler is ok
> but there is no assembler for nibz? so == useless.
> no C, no assembler, == not possible to use :(
> 
> a non working somesort of forht partially adopted
> but not really tested does not count as development tool.
> 
> a simple assembler would.
> 
> I personally dont like C, but unfortunatly can not fully avoid it
> either
> 
> Antti

Look at using a table driven user definable universal assembler

b. Farmer.  (I am back).

On Mar 18, 8:17=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
> So the only benefit I see a stack machine has is more compact code.

So, are we going to see a Nano-Blaze for the 6-LUT Xilinx parts ? ;)

-jg

On Mar 17, 7:06=A0pm, Jacko <jackokr...@gmail.com> wrote:
>
> There is now a link on the instruction set page presenting an english
> text description of the BO instruction. All other instructions follow
> a similar symbology.

Dude, you are really terrible at this.  In one place you tell people
about a CPU you designed with no specifics.  Another place you post a
link to a web page with very fuzzy descriptions of the instruction set
that is not usable.  Then here you post that you have added some more
explanation, but no link.  Are we supposed to search around to find
the link to your web page again?  I have no idea where to find it.

I may not be very tactful, but I really am trying to help you, not be
insulting.  I hope it doesn't come off that way.


Rick

Hal Murray wrote:
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful?  There aren't many projects done in C that are debugged
>> without an emulator.
> 
> I'm happy without a debugger, at least as long as the edit/compile/run
> cycle is fast.  Besides, a lot of the quirks I'm chasing are
> timing issues where you need a scope to see what's going on.
> 
> What do you use for a debugger when working on perl/python code?
> 
For perl, Open Perl IDE
http://open-perl-ide.sourceforge.net/

-urb

"Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com> writes:

> sure can use GCC as i already mentioned 4 posts ago :)
> but it not always as good as good macro assembler

I once wrote a microcode assembler *generator*. It would extract the
operand specs from the Verilog HDL source and generate an assembler on
the fly and then run it.

The only two hardcoded ops were "org" and "label". The program was
quite small, less than 200 lines of Common Lisp code. The assembler
was built on top of Common Lisp so you also got the powerful Common
Lisp macros and functions as a free feature.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 18 Mar 2009 11:24:45 GMT, Albert van der Horst wrote:

>The shallow stack of the transputer is lost on context
>switches for equal priority task. Together with the
>limitation where context switches could occur (only
>on conditional jumps) this accounts for a very practical
>design. (I would like to see a Ghz transputer with
>all the modern chip design tricks.)

Agreed wholeheartedly.  The Transputer suffered
badly because the technology that would make it
effective (particularly, very fast serial links)
was not available at the time; and the "prefix"
mechanism was too wasteful of code space for 
comfort; but it had some brilliantly clever
architectural ideas and I mourn its passing.

Context switches could happen only at "scheduling
points"; I think there were more of these than
merely conditional branches.  But whatever the
detail, the basic idea of choosing only to 
switch context when the stack is empty is 
very cool.  It requires very tight coupling 
among architecture, compiler and runtime
executive, though.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.