Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 139000

Article: 139000
Subject: Re: uB and external CPU communications
From: Koorndyk <kris.koorndyk@gmail.com>
Date: Wed, 18 Mar 2009 05:26:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 4:48=A0am, wolahr <w...@volamp.com> wrote:
> excuse my ignorance here, but what is a uB?

microblaze

Article: 139001
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Wed, 18 Mar 2009 05:36:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
\ FORTH Assembler for nibz
\
\ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc.

\ This file is part of Gforth.

\ Gforth is free software; you can redistribute it and/or
\ modify it under the terms of the GNU General Public License
\ as published by the Free Software Foundation, either version 3
\ of the License, or (at your option) any later version.

\ This program is distributed in the hope that it will be useful,
\ but WITHOUT ANY WARRANTY; without even the implied warranty of
\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
\ GNU General Public License for more details.

\ You should have received a copy of the GNU General Public License
\ along with this program. If not, see http://www.gnu.org/licenses/.
\
\ Autor:          Simon Jackson, BEng.
\
\ Information:
\
\ - Simple Assembler

\ only forth definitions

require asm/basic.fs

 also ASSEMBLER definitions

require asm/target.fs

 HERE                   ( Begin )

\ The assembler is very simple. All 16 opcodes are
\ defined immediate so they can be inlined into colon defs.

\ primary opcode constant writers

: BA 0 , ; immediate
: FI 1 , ; immediate
: RI 2 , ; immediate
: SI 3 , ; immediate

: DI 4 , ; immediate
: FA 5 , ; immediate
: RA 6 , ; immediate
: SA 7 , ; immediate

: BO 8 , ; immediate
: FO 9 , ; immediate
: RO 10 , ; immediate
: SO 11 , ; immediate

: SU 12 , ; immediate
: FE 13 , ; immediate
: RE 14 , ; immediate
: SE 15 , ; immediate

 HERE  SWAP -
 CR .( Length of Assembler: ) . .( Bytes ) CR

Article: 139002
Subject: Re: Zero operand CPUs
From: Paul Urbanus <urbpublic@hotmail.com>
Date: Wed, 18 Mar 2009 07:49:15 -0500
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:
> On Mar 18, 8:45 am, rickman <gnu...@gmail.com> wrote:
>> On Mar 17, 7:06 pm, 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
> 
> You are so right...
> I looked (again) the nibz web
> 
> downloaded the most promising document (tagged FEATURED!)
> 
> did not understand much, scrolled to the end of the document..
> where on the last line stands:
> 
> ".... ummmm ...."
> 
> guess this is what we all should be doing: ummmmmmm
> 
> now, if we compare nibz to Mproz3
> 
> then
> 1 mproz3 is MUCH smaller
> 2 has superiour docu
> 3 has VERY simple assembler with source code (single file just invoke
> gcc to compile it)
> 
> mproz3 is now available in VHDL form, and succesfully working in
> Silicon Blue FPGA :)
> 
> so it doesnt matter how many times the nibz may be better, without
> documentation
> and tools its useless for anybody except the author.
> 
> Antti
> 
> 
> 
> 
Antti - where did you find the mproz3 design?

My google searches consistently turn up 
ftp://137.193.64.130/pub/mproz/mproz3.zip, but this server appears to be 
down. Do you know of a mirror for this. Also, from what I've been able 
to read, this design was originally a schematic design. Did you convert it?

How does it compare to picoblaze in size, execution speed, and code density?

-Urb

Article: 139003
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 05:50:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 2:36=A0pm, Jacko <jackokr...@gmail.com> wrote:
> \ FORTH Assembler for nibz
> \
> \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc.
>
> \ This file is part of Gforth.
>
> \ Gforth is free software; you can redistribute it and/or
> \ modify it under the terms of the GNU General Public License
> \ as published by the Free Software Foundation, either version 3
> \ of the License, or (at your option) any later version.
>
> \ This program is distributed in the hope that it will be useful,
> \ but WITHOUT ANY WARRANTY; without even the implied warranty of
> \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the
> \ GNU General Public License for more details.
>
> \ You should have received a copy of the GNU General Public License
> \ along with this program. If not, seehttp://www.gnu.org/licenses/.
> \
> \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng.
> \
> \ Information:
> \
> \ - Simple Assembler
>
> \ only forth definitions
>
> require asm/basic.fs
>
> =A0also ASSEMBLER definitions
>
> require asm/target.fs
>
> =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin )
>
> \ The assembler is very simple. All 16 opcodes are
> \ defined immediate so they can be inlined into colon defs.
>
> \ primary opcode constant writers
>
> : BA 0 , ; immediate
> : FI 1 , ; immediate
> : RI 2 , ; immediate
> : SI 3 , ; immediate
>
> : DI 4 , ; immediate
> : FA 5 , ; immediate
> : RA 6 , ; immediate
> : SA 7 , ; immediate
>
> : BO 8 , ; immediate
> : FO 9 , ; immediate
> : RO 10 , ; immediate
> : SO 11 , ; immediate
>
> : SU 12 , ; immediate
> : FE 13 , ; immediate
> : RE 14 , ; immediate
> : SE 15 , ; immediate
>
> =A0HERE =A0SWAP -
> =A0CR .( Length of Assembler: ) . .( Bytes ) CR


Jacko, if you want other to understand, please make simple example:

1) test source file: TEST.ASM

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

inset asm op codes to write value 0xAA55 to IO address 0x2233 here

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

2) provide some executable file such that:

jackocompiler.exe TEST.ASM >TEST.BIN

produces a code ready to load into FPGA block ram
and when executed will write AA55 to address 2233

saying this is part of GForth... so what is ?
you are part of GForth? nibz is? your assembler is?

looking at your 2 LETTER code style, i have hard
times to understand how to

MOV OUTPORT, DATA


we all belive what you do does makes sense for you
but for others to use, ? no docu, no examples, no use..

eh i read you donation record, 0.00 so far eh my paypal
account is at 0 too, otherwise i would donate the 42$
what i did estimate to be your total earnings...

you do not need to try to rush so much, just do something
properly....

B16 is also stack based soft-core, but it HAS an assembler
please take a look, look how others have done assembler
for stack machine, its ok to look, you dont have to todo
everything from scratch

Antti














































Article: 139004
Subject: Bullshit! - Re: Zero operand CPUs
From: Helmar <helmwo@gmail.com>
Date: Wed, 18 Mar 2009 06:06:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

rickman wrote:
> I have been following the development of the ZPU, a zero operand
> processor for FPGAs.  The primary intent is to design a CPU that can
> span a range of sizes from very space efficient to high speed while
> being efficient at running C code.

What do you expect from something that does not need operands or has
only the operand "0" zero? It can not do much useful things - ok, it
could heat the room it is inside.
The purpose of a processor is to combine operational procedures with
one or more operands. It does these operations one by one.
If the CPU gets zero operands at all, it's very simple to make it high
speed or space efficient. It could be targeted by every language that
has a NOP operation.

I know, I do understand this in the wrong way, but it had to be told
anyway.

Regards,
-Helmar

Article: 139005
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 06:23:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 2:49=A0pm, Paul Urbanus <urbpub...@hotmail.com> wrote:
> Antti.Luk...@googlemail.com wrote:
> > On Mar 18, 8:45 am, rickman <gnu...@gmail.com> wrote:
> >> On Mar 17, 7:06 pm, 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. =A0In one place you tell people
> >> about a CPU you designed with no specifics. =A0Another place you post =
a
> >> link to a web page with very fuzzy descriptions of the instruction set
> >> that is not usable. =A0Then here you post that you have added some mor=
e
> >> explanation, but no link. =A0Are we supposed to search around to find
> >> the link to your web page again? =A0I have no idea where to find it.
>
> >> I may not be very tactful, but I really am trying to help you, not be
> >> insulting. =A0I hope it doesn't come off that way.
>
> >> Rick
>
> > You are so right...
> > I looked (again) the nibz web
>
> > downloaded the most promising document (tagged FEATURED!)
>
> > did not understand much, scrolled to the end of the document..
> > where on the last line stands:
>
> > ".... ummmm ...."
>
> > guess this is what we all should be doing: ummmmmmm
>
> > now, if we compare nibz to Mproz3
>
> > then
> > 1 mproz3 is MUCH smaller
> > 2 has superiour docu
> > 3 has VERY simple assembler with source code (single file just invoke
> > gcc to compile it)
>
> > mproz3 is now available in VHDL form, and succesfully working in
> > Silicon Blue FPGA :)
>
> > so it doesnt matter how many times the nibz may be better, without
> > documentation
> > and tools its useless for anybody except the author.
>
> > Antti
>
> Antti - where did you find the mproz3 design?
>
> My google searches consistently turn upftp://137.193.64.130/pub/mproz/mpr=
oz3.zip, but this server appears to be
> down. Do you know of a mirror for this. Also, from what I've been able
> to read, this design was originally a schematic design. Did you convert i=
t?
>
> How does it compare to picoblaze in size, execution speed, and code densi=
ty?
>
> -Urb

speed LOWER
code density WORSE

but: resources LESS
addressing space LARGER

the FTP seems to work
and the VHDL translated version is now available, just uploaded
http://groups.google.com/group/antti-brain/files?hl=3Den

cheers
Antti









Article: 139006
Subject: Documenting a simple CPU
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 18 Mar 2009 13:29:32 +0000
Links: << >>  << T >>  << A >>
Some of us have been a little frustrated by the 
hard-to-follow documentation of the nibz CPU.
I thought it might be useful, as a comparison,
to expose to public ridicule the documentation
for a toy CPU I developed as fodder for some of
our training courses.  It doesn't yet have an
assembler (sorry Antti!!!) but I hope you will
agree that the docs are complete enough for you 
to write one should you so wish.

I'm not trying to stir up interest in this CPU
design, even though I think it's quite cute; 
there are far too many RISC soft-cores out there
already.  I just wanted to give an example of how
you might go about documenting such a thing without
putting in too much effort.  Its instruction set
is roughly of the same complexity as nibz, I think.

http://www.oxfordbromley.plus.com/files/miniCPU/arch.pdf
-- 
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.

Article: 139007
Subject: Re: Documenting a simple CPU
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 06:41:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 3:29=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> Some of us have been a little frustrated by the
> hard-to-follow documentation of the nibz CPU.
> I thought it might be useful, as a comparison,
> to expose to public ridicule the documentation
> for a toy CPU I developed as fodder for some of
> our training courses. =A0It doesn't yet have an
> assembler (sorry Antti!!!) but I hope you will
> agree that the docs are complete enough for you
> to write one should you so wish.
>
> I'm not trying to stir up interest in this CPU
> design, even though I think it's quite cute;
> there are far too many RISC soft-cores out there
> already. =A0I just wanted to give an example of how
> you might go about documenting such a thing without
> putting in too much effort. =A0Its instruction set
> is roughly of the same complexity as nibz, I think.
>
> http://www.oxfordbromley.plus.com/files/miniCPU/arch.pdf
> --
> 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.

Hi

it is defenetly interesting already!
because it has human readable documentation

and creating an assembler based on the docu can be accomplished in
less than an hour

Antti




Article: 139008
Subject: false path assignment for clock boundary crossing.
From: axr0284 <axr0284@yahoo.com>
Date: Wed, 18 Mar 2009 06:44:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
 I have a design with multiple clock boundary crossings. I use the
double buffering method for all clock boundary crossings. I am using
Xilinx ISE to compile my code and would like to know if the following
false path setting is correct for my design:
I have four main clocks, dsp_clk, dsp_clk_div2, hkb_clk and
adc_two_clk.
All of the crossings occur between dsp_clk and the others.

These are the clock signals from the output of port CLK0 of their
respective DCM

TIMESPEC TS_dsp_clk_to_dsp_clk_div2 = FROM
"clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_dsp_clk_div2_0"
TIG;
TIMESPEC TS_dsp_clk_to_hkb_clk = FROM "clock_manager_dcm_dsp_clk_0" TO
"clock_manager_dcm_hkb_clk_0" TIG;
TIMESPEC TS_dsp_clk_adc_two_clk = FROM "clock_manager_dcm_dsp_clk_0"
TO "clock_manager_dcm_adc_two_clk_0" TIG;

Thanks,
Amish

Article: 139009
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Wed, 18 Mar 2009 06:51:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 18 Mar, 11:48, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 18, 8:45=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > 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. =A0In one place you tell people
> > about a CPU you designed with no specifics. =A0Another place you post a
> > link to a web page with very fuzzy descriptions of the instruction set
> > that is not usable. =A0Then here you post that you have added some more
> > explanation, but no link. =A0Are we supposed to search around to find
> > the link to your web page again? =A0I have no idea where to find it.
>
> > I may not be very tactful, but I really am trying to help you, not be
> > insulting. =A0I hope it doesn't come off that way.
>
> > Rick
>
> You are so right...
> I looked (again) the nibz web
>
> downloaded the most promising document (tagged FEATURED!)
>
> did not understand much, scrolled to the end of the document..
> where on the last line stands:
>
> ".... ummmm ...."
>
> guess this is what we all should be doing: ummmmmmm

The umm does make sense in terms of what the document was describing.

There is now a featured download of the instruction set at
http://nibz.googlecode.com

> now, if we compare nibz to Mproz3
>
> then
> 1 mproz3 is MUCH smaller
> 2 has superiour docu
> 3 has VERY simple assembler with source code (single file just invoke
> gcc to compile it)

And has a self modifying code tendancy.

> mproz3 is now available in VHDL form, and succesfully working in
> Silicon Blue FPGA :)

Excellent.

> so it doesnt matter how many times the nibz may be better, without
> documentation
> and tools its useless for anybody except the author.

In general true.

cheers jacko

Article: 139010
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: Jeff Fox <fox@ultratechnology.com>
Date: Wed, 18 Mar 2009 08:14:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote:
> What do you expect from something that does not need operands or has
> only the operand "0" zero? It can not do much useful things - ok, it
> could heat the room it is inside.

Zero operand just means that the top of the stack is the implied
operand for most instructions.  It means that a register decoding
phase is not needed in the execution of instructions because the
operand is the stack.

Instead of having to decode which registers are gated for input
and which register is gated for output, and set up the gates to
the ALU as some of the steps in executing an instruction the path
to operands is hard wired because it is the top of the stack.  So
there are no operands to decode.

It is not very clever to try to convince people that it means that
there are no arguements at all and thefore all it can do is NOP.

It certainly does not mean that it cannot do useful things.  After all
some languages like Forth are also zero operand because they use
the top of a parameter stack.  Parameters are still needed for
branching and for literals but they are not operand fields for
registers that require a decoding phase hence the name zero operand.

Some people will declare that programming a register machine is
just easiter than programming a stack machine.  Their argument
is that the compiler they use makes it easy or that they can
stay at a higher level of abstraction.

Some people will declare that programming a stack machine is just
easier than programming a register machine.  Their argument is that
their compiler and language is simpler and smaller and doesn't
need all that complicated register stuff.  They may say that to
program a register machine people need complex smart
compilers to hide the real complexity under the hood and they
prefer something simpler.

And all that is mostly a matter of whether they are thinking of
software in a style used on register machines or a style used
on stack machines or virtual stack machines.  If you use C
then you like C hardware and C software and may think stack
languages or stack hardware is harder for you to deal with.

If you use Forth then you may think stack software and stack
hardware is a lot simpler and easier to deal with than bigger
more complex tools and platforms.   People choose Forth
for embedded work to get smaller, cheaper, and lower
power solutions to problems than those available with the
bigger more expensive, more complex hardware and
software.

Which is easier depends entirely on what you know and
the problem at hand.

> The purpose of a processor is to combine operational procedures with
> one or more operands.

Yes of course.  The idea of 'zero operand' is that the arguments,
operands, are on the stacks.  It's just silly and stupid to argue
that
it means that there are no arguments and thus nothing useful.

> It does these operations one by one.
> If the CPU gets zero operands at all, it's very simple to make it high
> speed or space efficient.

And it may be easy to port software far more compact and space
efficient than register machine native code especially when the design
needs inlining and loop unrolling to ger around pipeline or cache
problems.

The idea is to also reduce power consumption and resources
required by the design.  The idea is to be able to execute more
compact stack based code than register based code to further
reduce cost and power consumption by reducing memory use.
The idea is to make the CPU easier to program and more
efficient with simple software rather than demanding the
biggest and most complex development tools.

> It could be targeted by every language that
> has a NOP operation.

That's just insulting and dumb.  Zero operand does not mean
NOP only. ;-)   That's a new Forth-hater sound-bite, Forth
and stacks are only good for doing NOPs. Only the most
ignorant will believe it. ;-)

> I know, I do understand this in the wrong way, but it had to be told
> anyway.

It did not have to be told!

Best Wishes

Article: 139011
Subject: Re: false path assignment for clock boundary crossing.
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 18 Mar 2009 09:06:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 9:44=A0am, axr0284 <axr0...@yahoo.com> wrote:
> Hi,
> =A0I have a design with multiple clock boundary crossings. I use the
> double buffering method for all clock boundary crossings. I am using
> Xilinx ISE to compile my code and would like to know if the following
> false path setting is correct for my design:
> I have four main clocks, dsp_clk, dsp_clk_div2, hkb_clk and
> adc_two_clk.
> All of the crossings occur between dsp_clk and the others.
>
> These are the clock signals from the output of port CLK0 of their
> respective DCM
>
> TIMESPEC TS_dsp_clk_to_dsp_clk_div2 =3D FROM
> "clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_dsp_clk_div2_0"
> TIG;
> TIMESPEC TS_dsp_clk_to_hkb_clk =3D FROM "clock_manager_dcm_dsp_clk_0" TO
> "clock_manager_dcm_hkb_clk_0" TIG;
> TIMESPEC TS_dsp_clk_adc_two_clk =3D FROM "clock_manager_dcm_dsp_clk_0"
> TO "clock_manager_dcm_adc_two_clk_0" TIG;
>
> Thanks,
> Amish

Personally, I think it is much better to explicitly state the signals
that cross boundaries and declare them to be multi-cycle (or false
path if you prefer).  That way one can cross check between the
contraints and real code to verify that yes indeed this domain is
handled properly by design.  [1]

By making the blanket statement all crossing between clock domain X
and clock domain Y are false paths (as it appears that to me that
you're doing) you're immediately assuming that you've properly
implemented the domain crossing logic correctly under all of the
following
- Now and forever into the future
- No matter how many design iterations your code goes through
- No matter who ever makes a change to that code.

Such clock domain crossing logic should be proven to be correct, not
assumed.

Kevin Jennings

[1] There are other aspects to this logic that need to be handled like
guaranteeing any handshake signals properly line up with the data, but
let's not get into that here, just limit this to double buffering of
async signals to get them synced to a clock.

Article: 139012
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 09:34:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 10:17=A0pm, 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.
>
> 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

too bad the S-6 is delaying sooooo looooong so others than the few EA
companies
can develop code for S-6/V-6

LUT6 hopefully means also SRL64 what would be cool, but eh it should
be now
a few months til the 11.1 release so the mortals will see the spec too
then

Antti









Article: 139013
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: Helmar <helmwo@gmail.com>
Date: Wed, 18 Mar 2009 09:36:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Jeff,

On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote:
> On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote:
>
> > What do you expect from something that does not need operands or has
> > only the operand "0" zero? It can not do much useful things - ok, it
> > could heat the room it is inside.
>
> Zero operand just means that the top of the stack is the implied
> operand for most instructions. =A0It means that a register decoding
> phase is not needed in the execution of instructions because the
> operand is the stack.

OK, same then: a TOS can not be the only operand. You very probably
mean of course that the stack contains the operands. This is indeed
clever but does not mean "zero operands". Regarding this "register
decoding phase" - well, you have to "decode" it if you make the
distinction between "operation" and "operand". But if you see "ADD A,
1" as a different operation than "ADD B,1", you do not have any
"phase" in front of knowing what operation is needed. It simply could
be two different operations. So if you term a "stack" layout based
thing "zero operand" you could also call every "register" based layout
to be "zero operand", as far as every register has its own
implementation of "ADD".

> Instead of having to decode which registers are gated for input
> and which register is gated for output, and set up the gates to
> the ALU as some of the steps in executing an instruction the path
> to operands is hard wired because it is the top of the stack. =A0So
> there are no operands to decode.

There are still operands to decode. It might be the stack is somewhere
in memory or it's something like a few registers without possibility
to address them. There are still operands and they need to be
addressed and as that also "decoded" (even if this is not needed by
the symbolical instruction representation called "machine code").

> It is not very clever to try to convince people that it means that
> there are no arguements at all and thefore all it can do is NOP.

Well, without further instruction, everybody will think it is so.

> It certainly does not mean that it cannot do useful things. =A0After all
> some languages like Forth are also zero operand because they use
> the top of a parameter stack. =A0Parameters are still needed for
> branching and for literals but they are not operand fields for
> registers that require a decoding phase hence the name zero operand.
>
> Some people will declare that programming a register machine is
> just easiter than programming a stack machine. =A0Their argument
> is that the compiler they use makes it easy or that they can
> stay at a higher level of abstraction.

;) OK, that declarations does not interest me, as far as even mobile
phones start to be implemented using x86 technology...

> Some people will declare that programming a stack machine is just
> easier than programming a register machine. =A0Their argument is that
> their compiler and language is simpler and smaller and doesn't
> need all that complicated register stuff. =A0They may say that to
> program a register machine people need complex smart
> compilers to hide the real complexity under the hood and they
> prefer something simpler.

OK, in Forth:

: foo dup ;
: foo1 ! ;
: foo2 swap foo tuck foo1 ;

This now looks like a completely "useless" complicated sequence,
nobody would write this way.
The truth is, that the more you use that nice "symbolic" stuff in
Forth, the more that "useless" complicated sequences occur in output.
If you want to allow your users to use that symbolic stuff - and you
want to avoid too "useless" operations, even the stack based compiler-
thing has to optimize. Except for few, simple loophole-optimizations,
the stack based design of a processor does not help with it. The
compiler gets at least as complicated as every other - or maybe even
more complex (this would have to be done first I think).

> And all that is mostly a matter of whether they are thinking of
> software in a style used on register machines or a style used
> on stack machines or virtual stack machines. =A0If you use C
> then you like C hardware and C software and may think stack
> languages or stack hardware is harder for you to deal with.
>
> If you use Forth then you may think stack software and stack
> hardware is a lot simpler and easier to deal with than bigger
> more complex tools and platforms. =A0 People choose Forth
> for embedded work to get smaller, cheaper, and lower
> power solutions to problems than those available with the
> bigger more expensive, more complex hardware and
> software.

OK.

> Which is easier depends entirely on what you know and
> the problem at hand.

Sure? I mean the "problem at hand"? It would be interesting to know if
there are differences depending on the problem.

> > The purpose of a processor is to combine operational procedures with
> > one or more operands.
>
> Yes of course. =A0The idea of 'zero operand' is that the arguments,
> operands, are on the stacks. =A0It's just silly and stupid to argue
> that
> it means that there are no arguments and thus nothing useful.
>
> > It does these operations one by one.
> > If the CPU gets zero operands at all, it's very simple to make it high
> > speed or space efficient.
>
> And it may be easy to port software far more compact and space
> efficient than register machine native code especially when the design
> needs inlining and loop unrolling to ger around pipeline or cache
> problems.
>
> The idea is to also reduce power consumption and resources
> required by the design. =A0The idea is to be able to execute more
> compact stack based code than register based code to further
> reduce cost and power consumption by reducing memory use.
> The idea is to make the CPU easier to program and more
> efficient with simple software rather than demanding the
> biggest and most complex development tools.
>
> > It could be targeted by every language that
> > has a NOP operation.
>
> That's just insulting and dumb. =A0Zero operand does not mean
> NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth
> and stacks are only good for doing NOPs. Only the most
> ignorant will believe it. ;-)

;)

Regards,
-Helmar

Article: 139014
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 09:46:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 6:36=A0pm, Helmar <hel...@gmail.com> wrote:
> Hi Jeff,
>
> On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote:
>
> > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote:
>
> > > What do you expect from something that does not need operands or has
> > > only the operand "0" zero? It can not do much useful things - ok, it
> > > could heat the room it is inside.
>
> > Zero operand just means that the top of the stack is the implied
> > operand for most instructions. =A0It means that a register decoding
> > phase is not needed in the execution of instructions because the
> > operand is the stack.
>
> OK, same then: a TOS can not be the only operand. You very probably
> mean of course that the stack contains the operands. This is indeed
> clever but does not mean "zero operands". Regarding this "register
> decoding phase" - well, you have to "decode" it if you make the
> distinction between "operation" and "operand". But if you see "ADD A,
> 1" as a different operation than "ADD B,1", you do not have any
> "phase" in front of knowing what operation is needed. It simply could
> be two different operations. So if you term a "stack" layout based
> thing "zero operand" you could also call every "register" based layout
> to be "zero operand", as far as every register has its own
> implementation of "ADD".
>
> > Instead of having to decode which registers are gated for input
> > and which register is gated for output, and set up the gates to
> > the ALU as some of the steps in executing an instruction the path
> > to operands is hard wired because it is the top of the stack. =A0So
> > there are no operands to decode.
>
> There are still operands to decode. It might be the stack is somewhere
> in memory or it's something like a few registers without possibility
> to address them. There are still operands and they need to be
> addressed and as that also "decoded" (even if this is not needed by
> the symbolical instruction representation called "machine code").
>
> > It is not very clever to try to convince people that it means that
> > there are no arguements at all and thefore all it can do is NOP.
>
> Well, without further instruction, everybody will think it is so.
>
> > It certainly does not mean that it cannot do useful things. =A0After al=
l
> > some languages like Forth are also zero operand because they use
> > the top of a parameter stack. =A0Parameters are still needed for
> > branching and for literals but they are not operand fields for
> > registers that require a decoding phase hence the name zero operand.
>
> > Some people will declare that programming a register machine is
> > just easiter than programming a stack machine. =A0Their argument
> > is that the compiler they use makes it easy or that they can
> > stay at a higher level of abstraction.
>
> ;) OK, that declarations does not interest me, as far as even mobile
> phones start to be implemented using x86 technology...
>
> > Some people will declare that programming a stack machine is just
> > easier than programming a register machine. =A0Their argument is that
> > their compiler and language is simpler and smaller and doesn't
> > need all that complicated register stuff. =A0They may say that to
> > program a register machine people need complex smart
> > compilers to hide the real complexity under the hood and they
> > prefer something simpler.
>
> OK, in Forth:
>
> : foo dup ;
> : foo1 ! ;
> : foo2 swap foo tuck foo1 ;
>
> This now looks like a completely "useless" complicated sequence,
> nobody would write this way.
> The truth is, that the more you use that nice "symbolic" stuff in
> Forth, the more that "useless" complicated sequences occur in output.
> If you want to allow your users to use that symbolic stuff - and you
> want to avoid too "useless" operations, even the stack based compiler-
> thing has to optimize. Except for few, simple loophole-optimizations,
> the stack based design of a processor does not help with it. The
> compiler gets at least as complicated as every other - or maybe even
> more complex (this would have to be done first I think).
>
> > And all that is mostly a matter of whether they are thinking of
> > software in a style used on register machines or a style used
> > on stack machines or virtual stack machines. =A0If you use C
> > then you like C hardware and C software and may think stack
> > languages or stack hardware is harder for you to deal with.
>
> > If you use Forth then you may think stack software and stack
> > hardware is a lot simpler and easier to deal with than bigger
> > more complex tools and platforms. =A0 People choose Forth
> > for embedded work to get smaller, cheaper, and lower
> > power solutions to problems than those available with the
> > bigger more expensive, more complex hardware and
> > software.
>
> OK.
>
> > Which is easier depends entirely on what you know and
> > the problem at hand.
>
> Sure? I mean the "problem at hand"? It would be interesting to know if
> there are differences depending on the problem.
>
>
>
>
>
> > > The purpose of a processor is to combine operational procedures with
> > > one or more operands.
>
> > Yes of course. =A0The idea of 'zero operand' is that the arguments,
> > operands, are on the stacks. =A0It's just silly and stupid to argue
> > that
> > it means that there are no arguments and thus nothing useful.
>
> > > It does these operations one by one.
> > > If the CPU gets zero operands at all, it's very simple to make it hig=
h
> > > speed or space efficient.
>
> > And it may be easy to port software far more compact and space
> > efficient than register machine native code especially when the design
> > needs inlining and loop unrolling to ger around pipeline or cache
> > problems.
>
> > The idea is to also reduce power consumption and resources
> > required by the design. =A0The idea is to be able to execute more
> > compact stack based code than register based code to further
> > reduce cost and power consumption by reducing memory use.
> > The idea is to make the CPU easier to program and more
> > efficient with simple software rather than demanding the
> > biggest and most complex development tools.
>
> > > It could be targeted by every language that
> > > has a NOP operation.
>
> > That's just insulting and dumb. =A0Zero operand does not mean
> > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth
> > and stacks are only good for doing NOPs. Only the most
> > ignorant will believe it. ;-)
>
> ;)
>
> Regards,
> -Helmar- Hide quoted text -
>
> - Show quoted text -

Jeff & Helmar

another holy war?

there are pro and contra for everything.

what is sure is that as of today the register based (or maybe 0
register ones like mproz3)
small FPGA oriented soft-core processors are EASIER to deal with then
those that
are forth like and stack based
.

be the reason inbetween the ears, or in bad documentation or missing
tools, whatever.
Thing is non-stack based small soft-cores are easier for normal FPGA
users
.

I would not mind if it would be the other way around, but it isnt. So
some forth
guy could make some effort to describe and document the use of some
small SoC that uses stack - based core and is not programmed in C
(that is some
thing else then ZPU what is stack cpu with GCC support)

Antti
(hm i should look the B16.. again )

Article: 139015
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: zwsdotcom@gmail.com
Date: Wed, 18 Mar 2009 09:51:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 9:06=A0am, Helmar <hel...@gmail.com> wrote:

> What do you expect from something that does not need operands or has

Studying first-year computer science (machine architecture) might be
helpful to you, since this is very standard terminology. Of course
relatively few people have worked on zero-operand ISAs but I guess
most people in this NG have worked extensively with 1- and 2-operand
machines, and probably 3-operand also.

Article: 139016
Subject: Re: Zero operand CPUs
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 Mar 2009 09:59:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 8:36=A0am, Jacko <jackokr...@gmail.com> wrote:
> \ FORTH Assembler for nibz
> \
> \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc.
>
> \ This file is part of Gforth.
>
> \ Gforth is free software; you can redistribute it and/or
> \ modify it under the terms of the GNU General Public License
> \ as published by the Free Software Foundation, either version 3
> \ of the License, or (at your option) any later version.
>
> \ This program is distributed in the hope that it will be useful,
> \ but WITHOUT ANY WARRANTY; without even the implied warranty of
> \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the
> \ GNU General Public License for more details.
>
> \ You should have received a copy of the GNU General Public License
> \ along with this program. If not, seehttp://www.gnu.org/licenses/.
> \
> \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng.
> \
> \ Information:
> \
> \ - Simple Assembler
>
> \ only forth definitions
>
> require asm/basic.fs
>
> =A0also ASSEMBLER definitions
>
> require asm/target.fs
>
> =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin )
>
> \ The assembler is very simple. All 16 opcodes are
> \ defined immediate so they can be inlined into colon defs.
>
> \ primary opcode constant writers
>
> : BA 0 , ; immediate
> : FI 1 , ; immediate
> : RI 2 , ; immediate
> : SI 3 , ; immediate
>
> : DI 4 , ; immediate
> : FA 5 , ; immediate
> : RA 6 , ; immediate
> : SA 7 , ; immediate
>
> : BO 8 , ; immediate
> : FO 9 , ; immediate
> : RO 10 , ; immediate
> : SO 11 , ; immediate
>
> : SU 12 , ; immediate
> : FE 13 , ; immediate
> : RE 14 , ; immediate
> : SE 15 , ; immediate
>
> =A0HERE =A0SWAP -
> =A0CR .( Length of Assembler: ) . .( Bytes ) CR

What instruction is a CALL?  How do you specify the address?  How do
you specify literal data?

Rick

Article: 139017
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: Helmar <helmwo@gmail.com>
Date: Wed, 18 Mar 2009 10:01:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 12:51=A0pm, zwsdot...@gmail.com wrote:
> On Mar 18, 9:06=A0am, Helmar <hel...@gmail.com> wrote:
>
> > What do you expect from something that does not need operands or has
>
> Studying first-year computer science (machine architecture) might be
> helpful to you, since this is very standard terminology. Of course
> relatively few people have worked on zero-operand ISAs but I guess
> most people in this NG have worked extensively with 1- and 2-operand
> machines, and probably 3-operand also.

Obvious is that I only studied it the first year (it was in conflict
with my "philosophy"-schedules). And in this case it did not help,
since I studied "formal logic" after it. You should be sure that I
know that 2-operand machines would be acceptable for me, while I do
have problems with 1-operand too (may it be zero "0" or not). I btw.
can not even remember that some operations had no operands at all -
except maybe something like NOP, while even this had "operands" like
the program counter that would be increased.

That far, be nice not rude,
-Helmar

Article: 139018
Subject: Xilinx XAPP052 LFSR and its understanding
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 18 Mar 2009 10:04:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I want to generate a random number in a FPGA chip and in a natural way
it leads to a famous paper Xilinx XAPP052 authored by Peter Alfke:
"Efficient Shift Register, LFSR Counters, and Long Pseudo-Random
Sequence Generators".

I have two problems with the note.

1. I don't understand "Divide-by-5 to 16 counter". I appreciate if
someone explain the Table 2 and Figure 2 in more details.

2. In Figure 5, there is an equation: (Q3 xnor Q4) xor (Q1 and Q2 and
Q3 and Q4).
(Q3 xnor Q4) is required to generate 4-bit LFSR counter. (Q1 and Q2
and Q3 and Q4) is used to avoid a dead-lock situation from happening
when Q1-Q4 = '1'.

Now the 4-bit LFSR counter dead-lock situation should be extended to
any bits long LFSR counter if 2 elements XNOR operation is needed.
Especially in Figure 5 for 63-bit LFSR counter. When all 63-bits are
'1', it would be dead-locked into the all '1' position, because (Q62
xnor Q63) = '1' if both Q63 and Q62 are '1'.  But the situation is
excluded into the equation in Figure 5.

In another words, if a seed data is closing or equal to all '1'
situation, the LFSR is a shorter random number generator than its
claim of a 63-bit length generator. There is no way to exactly know if
a seed data is closing to all '1' situation.

We can add logic equation as 4-bit situation does as follows:
(Q62 xnor Q63) xor (Q1 and Q2 and ... and Q63).

There is a new question: If there is a more clever idea to do the same
things to avoid the 63-bit dead-lock situation from happening?

Weng


Article: 139019
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 Mar 2009 10:07:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
What are you talking about.  I saw your other post and realized
immediately that you were making a joke.  I saw Jeff's reply and
realized that he misunderstood you.  Then I saw this reply and
realized that I was wrong and you ***WEREN'T KIDDING***!!!

Man, some people just don't get it.  Some of the stuff you say below
is either from lala land or you are still pulling people's legs.

So are you for real?  Is your real name, Amelia Bedelia?

Rick


On Mar 18, 12:36=A0pm, Helmar <hel...@gmail.com> wrote:
> Hi Jeff,
>
> On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote:
>
> > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote:
>
> > > What do you expect from something that does not need operands or has
> > > only the operand "0" zero? It can not do much useful things - ok, it
> > > could heat the room it is inside.
>
> > Zero operand just means that the top of the stack is the implied
> > operand for most instructions. =A0It means that a register decoding
> > phase is not needed in the execution of instructions because the
> > operand is the stack.
>
> OK, same then: a TOS can not be the only operand. You very probably
> mean of course that the stack contains the operands. This is indeed
> clever but does not mean "zero operands". Regarding this "register
> decoding phase" - well, you have to "decode" it if you make the
> distinction between "operation" and "operand". But if you see "ADD A,
> 1" as a different operation than "ADD B,1", you do not have any
> "phase" in front of knowing what operation is needed. It simply could
> be two different operations. So if you term a "stack" layout based
> thing "zero operand" you could also call every "register" based layout
> to be "zero operand", as far as every register has its own
> implementation of "ADD".
>
> > Instead of having to decode which registers are gated for input
> > and which register is gated for output, and set up the gates to
> > the ALU as some of the steps in executing an instruction the path
> > to operands is hard wired because it is the top of the stack. =A0So
> > there are no operands to decode.
>
> There are still operands to decode. It might be the stack is somewhere
> in memory or it's something like a few registers without possibility
> to address them. There are still operands and they need to be
> addressed and as that also "decoded" (even if this is not needed by
> the symbolical instruction representation called "machine code").
>
> > It is not very clever to try to convince people that it means that
> > there are no arguements at all and thefore all it can do is NOP.
>
> Well, without further instruction, everybody will think it is so.
>
> > It certainly does not mean that it cannot do useful things. =A0After al=
l
> > some languages like Forth are also zero operand because they use
> > the top of a parameter stack. =A0Parameters are still needed for
> > branching and for literals but they are not operand fields for
> > registers that require a decoding phase hence the name zero operand.
>
> > Some people will declare that programming a register machine is
> > just easiter than programming a stack machine. =A0Their argument
> > is that the compiler they use makes it easy or that they can
> > stay at a higher level of abstraction.
>
> ;) OK, that declarations does not interest me, as far as even mobile
> phones start to be implemented using x86 technology...
>
> > Some people will declare that programming a stack machine is just
> > easier than programming a register machine. =A0Their argument is that
> > their compiler and language is simpler and smaller and doesn't
> > need all that complicated register stuff. =A0They may say that to
> > program a register machine people need complex smart
> > compilers to hide the real complexity under the hood and they
> > prefer something simpler.
>
> OK, in Forth:
>
> : foo dup ;
> : foo1 ! ;
> : foo2 swap foo tuck foo1 ;
>
> This now looks like a completely "useless" complicated sequence,
> nobody would write this way.
> The truth is, that the more you use that nice "symbolic" stuff in
> Forth, the more that "useless" complicated sequences occur in output.
> If you want to allow your users to use that symbolic stuff - and you
> want to avoid too "useless" operations, even the stack based compiler-
> thing has to optimize. Except for few, simple loophole-optimizations,
> the stack based design of a processor does not help with it. The
> compiler gets at least as complicated as every other - or maybe even
> more complex (this would have to be done first I think).
>
> > And all that is mostly a matter of whether they are thinking of
> > software in a style used on register machines or a style used
> > on stack machines or virtual stack machines. =A0If you use C
> > then you like C hardware and C software and may think stack
> > languages or stack hardware is harder for you to deal with.
>
> > If you use Forth then you may think stack software and stack
> > hardware is a lot simpler and easier to deal with than bigger
> > more complex tools and platforms. =A0 People choose Forth
> > for embedded work to get smaller, cheaper, and lower
> > power solutions to problems than those available with the
> > bigger more expensive, more complex hardware and
> > software.
>
> OK.
>
> > Which is easier depends entirely on what you know and
> > the problem at hand.
>
> Sure? I mean the "problem at hand"? It would be interesting to know if
> there are differences depending on the problem.
>
>
>
> > > The purpose of a processor is to combine operational procedures with
> > > one or more operands.
>
> > Yes of course. =A0The idea of 'zero operand' is that the arguments,
> > operands, are on the stacks. =A0It's just silly and stupid to argue
> > that
> > it means that there are no arguments and thus nothing useful.
>
> > > It does these operations one by one.
> > > If the CPU gets zero operands at all, it's very simple to make it hig=
h
> > > speed or space efficient.
>
> > And it may be easy to port software far more compact and space
> > efficient than register machine native code especially when the design
> > needs inlining and loop unrolling to ger around pipeline or cache
> > problems.
>
> > The idea is to also reduce power consumption and resources
> > required by the design. =A0The idea is to be able to execute more
> > compact stack based code than register based code to further
> > reduce cost and power consumption by reducing memory use.
> > The idea is to make the CPU easier to program and more
> > efficient with simple software rather than demanding the
> > biggest and most complex development tools.
>
> > > It could be targeted by every language that
> > > has a NOP operation.
>
> > That's just insulting and dumb. =A0Zero operand does not mean
> > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth
> > and stacks are only good for doing NOPs. Only the most
> > ignorant will believe it. ;-)
>
> ;)
>
> Regards,
> -Helmar


Article: 139020
Subject: Re: Documenting a simple CPU
From: jon@beniston.com
Date: Wed, 18 Mar 2009 10:14:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Or you could use something like cgen (http://sourceware.org/cgen/),
then you can have your assembler and simulator generated automatically
for you (no reason why this couldn't also be extended to generating
GCC backend and prototype HDL too).

Jon

Article: 139021
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: Helmar <helmwo@gmail.com>
Date: Wed, 18 Mar 2009 10:24:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
You want an answer from *this* writing below?
Are you kidding?

-Helmar


On Mar 18, 1:07=A0pm, rickman <gnu...@gmail.com> wrote:
> What are you talking about. =A0I saw your other post and realized
> immediately that you were making a joke. =A0I saw Jeff's reply and
> realized that he misunderstood you. =A0Then I saw this reply and
> realized that I was wrong and you ***WEREN'T KIDDING***!!!
>
> Man, some people just don't get it. =A0Some of the stuff you say below
> is either from lala land or you are still pulling people's legs.
>
> So are you for real? =A0Is your real name, Amelia Bedelia?
>
> Rick
>
> On Mar 18, 12:36=A0pm, Helmar <hel...@gmail.com> wrote:
>
>
>
> > Hi Jeff,
>
> > On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote:
>
> > > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote:
>
> > > > What do you expect from something that does not need operands or ha=
s
> > > > only the operand "0" zero? It can not do much useful things - ok, i=
t
> > > > could heat the room it is inside.
>
> > > Zero operand just means that the top of the stack is the implied
> > > operand for most instructions. =A0It means that a register decoding
> > > phase is not needed in the execution of instructions because the
> > > operand is the stack.
>
> > OK, same then: a TOS can not be the only operand. You very probably
> > mean of course that the stack contains the operands. This is indeed
> > clever but does not mean "zero operands". Regarding this "register
> > decoding phase" - well, you have to "decode" it if you make the
> > distinction between "operation" and "operand". But if you see "ADD A,
> > 1" as a different operation than "ADD B,1", you do not have any
> > "phase" in front of knowing what operation is needed. It simply could
> > be two different operations. So if you term a "stack" layout based
> > thing "zero operand" you could also call every "register" based layout
> > to be "zero operand", as far as every register has its own
> > implementation of "ADD".
>
> > > Instead of having to decode which registers are gated for input
> > > and which register is gated for output, and set up the gates to
> > > the ALU as some of the steps in executing an instruction the path
> > > to operands is hard wired because it is the top of the stack. =A0So
> > > there are no operands to decode.
>
> > There are still operands to decode. It might be the stack is somewhere
> > in memory or it's something like a few registers without possibility
> > to address them. There are still operands and they need to be
> > addressed and as that also "decoded" (even if this is not needed by
> > the symbolical instruction representation called "machine code").
>
> > > It is not very clever to try to convince people that it means that
> > > there are no arguements at all and thefore all it can do is NOP.
>
> > Well, without further instruction, everybody will think it is so.
>
> > > It certainly does not mean that it cannot do useful things. =A0After =
all
> > > some languages like Forth are also zero operand because they use
> > > the top of a parameter stack. =A0Parameters are still needed for
> > > branching and for literals but they are not operand fields for
> > > registers that require a decoding phase hence the name zero operand.
>
> > > Some people will declare that programming a register machine is
> > > just easiter than programming a stack machine. =A0Their argument
> > > is that the compiler they use makes it easy or that they can
> > > stay at a higher level of abstraction.
>
> > ;) OK, that declarations does not interest me, as far as even mobile
> > phones start to be implemented using x86 technology...
>
> > > Some people will declare that programming a stack machine is just
> > > easier than programming a register machine. =A0Their argument is that
> > > their compiler and language is simpler and smaller and doesn't
> > > need all that complicated register stuff. =A0They may say that to
> > > program a register machine people need complex smart
> > > compilers to hide the real complexity under the hood and they
> > > prefer something simpler.
>
> > OK, in Forth:
>
> > : foo dup ;
> > : foo1 ! ;
> > : foo2 swap foo tuck foo1 ;
>
> > This now looks like a completely "useless" complicated sequence,
> > nobody would write this way.
> > The truth is, that the more you use that nice "symbolic" stuff in
> > Forth, the more that "useless" complicated sequences occur in output.
> > If you want to allow your users to use that symbolic stuff - and you
> > want to avoid too "useless" operations, even the stack based compiler-
> > thing has to optimize. Except for few, simple loophole-optimizations,
> > the stack based design of a processor does not help with it. The
> > compiler gets at least as complicated as every other - or maybe even
> > more complex (this would have to be done first I think).
>
> > > And all that is mostly a matter of whether they are thinking of
> > > software in a style used on register machines or a style used
> > > on stack machines or virtual stack machines. =A0If you use C
> > > then you like C hardware and C software and may think stack
> > > languages or stack hardware is harder for you to deal with.
>
> > > If you use Forth then you may think stack software and stack
> > > hardware is a lot simpler and easier to deal with than bigger
> > > more complex tools and platforms. =A0 People choose Forth
> > > for embedded work to get smaller, cheaper, and lower
> > > power solutions to problems than those available with the
> > > bigger more expensive, more complex hardware and
> > > software.
>
> > OK.
>
> > > Which is easier depends entirely on what you know and
> > > the problem at hand.
>
> > Sure? I mean the "problem at hand"? It would be interesting to know if
> > there are differences depending on the problem.
>
> > > > The purpose of a processor is to combine operational procedures wit=
h
> > > > one or more operands.
>
> > > Yes of course. =A0The idea of 'zero operand' is that the arguments,
> > > operands, are on the stacks. =A0It's just silly and stupid to argue
> > > that
> > > it means that there are no arguments and thus nothing useful.
>
> > > > It does these operations one by one.
> > > > If the CPU gets zero operands at all, it's very simple to make it h=
igh
> > > > speed or space efficient.
>
> > > And it may be easy to port software far more compact and space
> > > efficient than register machine native code especially when the desig=
n
> > > needs inlining and loop unrolling to ger around pipeline or cache
> > > problems.
>
> > > The idea is to also reduce power consumption and resources
> > > required by the design. =A0The idea is to be able to execute more
> > > compact stack based code than register based code to further
> > > reduce cost and power consumption by reducing memory use.
> > > The idea is to make the CPU easier to program and more
> > > efficient with simple software rather than demanding the
> > > biggest and most complex development tools.
>
> > > > It could be targeted by every language that
> > > > has a NOP operation.
>
> > > That's just insulting and dumb. =A0Zero operand does not mean
> > > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth
> > > and stacks are only good for doing NOPs. Only the most
> > > ignorant will believe it. ;-)
>
> > ;)
>
> > Regards,
> > -Helmar


Article: 139022
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Wed, 18 Mar 2009 10:54:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 18 Mar, 16:59, rickman <gnu...@gmail.com> wrote:
> On Mar 18, 8:36 am, Jacko <jackokr...@gmail.com> wrote:
>
>
>
> > \ FORTH Assembler for nibz
> > \
> > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc.
>
> > \ This file is part of Gforth.
>
> > \ Gforth is free software; you can redistribute it and/or
> > \ modify it under the terms of the GNU General Public License
> > \ as published by the Free Software Foundation, either version 3
> > \ of the License, or (at your option) any later version.
>
> > \ This program is distributed in the hope that it will be useful,
> > \ but WITHOUT ANY WARRANTY; without even the implied warranty of
> > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > \ GNU General Public License for more details.
>
> > \ You should have received a copy of the GNU General Public License
> > \ along with this program. If not, seehttp://www.gnu.org/licenses/.
> > \
> > \ Autor:          Simon Jackson, BEng.
> > \
> > \ Information:
> > \
> > \ - Simple Assembler
>
> > \ only forth definitions
>
> > require asm/basic.fs
>
> >  also ASSEMBLER definitions
>
> > require asm/target.fs
>
> >  HERE                   ( Begin )
>
> > \ The assembler is very simple. All 16 opcodes are
> > \ defined immediate so they can be inlined into colon defs.
>
> > \ primary opcode constant writers
>
> > : BA 0 , ; immediate
> > : FI 1 , ; immediate
> > : RI 2 , ; immediate
> > : SI 3 , ; immediate
>
> > : DI 4 , ; immediate
> > : FA 5 , ; immediate
> > : RA 6 , ; immediate
> > : SA 7 , ; immediate
>
> > : BO 8 , ; immediate
> > : FO 9 , ; immediate
> > : RO 10 , ; immediate
> > : SO 11 , ; immediate
>
> > : SU 12 , ; immediate
> > : FE 13 , ; immediate
> > : RE 14 , ; immediate
> > : SE 15 , ; immediate
>
> >  HERE  SWAP -
> >  CR .( Length of Assembler: ) . .( Bytes ) CR
>
> What instruction is a CALL?  How do you specify the address?  How do
> you specify literal data?
>
> Rick

$addr ,

Article: 139023
Subject: Re: Bullshit! - Re: Zero operand CPUs
From: Helmar <helmwo@gmail.com>
Date: Wed, 18 Mar 2009 10:59:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Maybe it's you ;)
> > Man, some people just don't get it.

Regarding my real name: Helmar.

What you and others not get is: "Zero Operand Cpu" is something like
"Wir sind Papst!" in Germany. Why did not FORTH INC., forth.com make
advertise with "The Zero-Operand Language!" all the last years? It
would save a lot of time for programmers, not to care about operands.
I guess they do not for good reasons.

-Helmar (...censored...)


Article: 139024
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 11:42:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 7:54=A0pm, Jacko <jackokr...@gmail.com> wrote:
> On 18 Mar, 16:59, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 18, 8:36 am, Jacko <jackokr...@gmail.com> wrote:
>
> > > \ FORTH Assembler for nibz
> > > \
> > > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc.
>
> > > \ This file is part of Gforth.
>
> > > \ Gforth is free software; you can redistribute it and/or
> > > \ modify it under the terms of the GNU General Public License
> > > \ as published by the Free Software Foundation, either version 3
> > > \ of the License, or (at your option) any later version.
>
> > > \ This program is distributed in the hope that it will be useful,
> > > \ but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the
> > > \ GNU General Public License for more details.
>
> > > \ You should have received a copy of the GNU General Public License
> > > \ along with this program. If not, seehttp://www.gnu.org/licenses/.
> > > \
> > > \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng.
> > > \
> > > \ Information:
> > > \
> > > \ - Simple Assembler
>
> > > \ only forth definitions
>
> > > require asm/basic.fs
>
> > > =A0also ASSEMBLER definitions
>
> > > require asm/target.fs
>
> > > =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin )
>
> > > \ The assembler is very simple. All 16 opcodes are
> > > \ defined immediate so they can be inlined into colon defs.
>
> > > \ primary opcode constant writers
>
> > > : BA 0 , ; immediate
> > > : FI 1 , ; immediate
> > > : RI 2 , ; immediate
> > > : SI 3 , ; immediate
>
> > > : DI 4 , ; immediate
> > > : FA 5 , ; immediate
> > > : RA 6 , ; immediate
> > > : SA 7 , ; immediate
>
> > > : BO 8 , ; immediate
> > > : FO 9 , ; immediate
> > > : RO 10 , ; immediate
> > > : SO 11 , ; immediate
>
> > > : SU 12 , ; immediate
> > > : FE 13 , ; immediate
> > > : RE 14 , ; immediate
> > > : SE 15 , ; immediate
>
> > > =A0HERE =A0SWAP -
> > > =A0CR .( Length of Assembler: ) . .( Bytes ) CR
>
> > What instruction is a CALL? =A0How do you specify the address? =A0How d=
o
> > you specify literal data?
>
> > Rick
>
> $addr ,

Jacko

your comments are just getting more and more fuzzy and cryptic.

is that on purpose?

Antti




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search