Zero operand CPUs

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

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

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

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 )

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.

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

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

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

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

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 ,