Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41165 > unrolled thread

Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH?

Back to article view | Back to comp.lang.forth

Contents

  Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? mfanyikazi@gmail.com - 2015-08-07 09:44 -0700
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Jason Damisch <jasondamisch@yahoo.com> - 2015-08-07 10:13 -0700
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? rickman <gnuarm@gmail.com> - 2015-08-07 13:21 -0400
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Jason Damisch <jasondamisch@yahoo.com> - 2015-08-07 10:24 -0700
    Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Mark Wills <markwills1970@gmail.com> - 2015-08-07 16:59 -0700
      Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? rickman <gnuarm@gmail.com> - 2015-08-08 01:11 -0400
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-08 01:38 -0400
      Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-08-07 23:42 -0700
        Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Coos Haak <chforth@hccnet.nl> - 2015-08-08 19:41 +0200
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-07 23:03 -1000
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? mhx@iae.nl - 2015-08-08 02:31 -0700
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-08 11:27 +0100
      Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-08 15:28 +0000
      Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-09 03:24 -0400
        Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? mfanyikazi@gmail.com - 2015-08-09 01:59 -0700
        Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? rickman <gnuarm@gmail.com> - 2015-08-09 15:15 -0400
    Re: Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-08-08 13:55 -0700

#41165 — Which is more practical , 64 bit , 32 bit or 16 bit CPU for FORTH?

I was just wondering why many Forth CPU's are desinged to be 16 bit whereas a 64 bit CPU would be more practial in today's data processing needs.

I think even when working with sensor data; a 64 bit Forth CPU would be more practical than a 16 bit CPU. Is it because Chuck Moore said so and people are afarid to go 64 bit , or is it a more technical thing like power consumption? I think if designed well with todays minuaturised memory circuits a 64 bit CPU could easily compete with a 16 bit CPU (speed , size , power consumption) and seriously out perform it.

If I am missing something , please someone enlighten me.

[toc] | [next] | [standalone]

#41168

Well classically Forth is 16 bit.
16 bits seem like enough program space to do most things with.
This may not be 100% true but it is true enough to carry some
weight.

When you gain something you lose something, and when you lose
something you gain something.  16 bits is cheaper and alot of
the more current Forth work has been done in imbedded systems
which are medium to small.  For those kinds of jobs cheaper
parts are preferred, and you only need about that much program
space anyway.  16 bit chips are cheap, or 8 bit ones onto 
which 16 bit Forths have been implemented are cheap.

But, you may find that you need 32 bits or 64 bits to do 
something.  Ideally, in my opinion, there should be 16
bit Forth CPUs, 32 bit ones, and 64 bit ones, but we only
have now FPGA and GA144 available to us now.

Jason

[toc] | [prev] | [next] | [standalone]

#41169

On 8/7/2015 12:44 PM, mfanyikazi@gmail.com wrote:
> I was just wondering why many Forth CPU's are desinged to be 16 bit whereas a 64 bit CPU would be more practial in today's data processing needs.
>
> I think even when working with sensor data; a 64 bit Forth CPU would be more practical than a 16 bit CPU. Is it because Chuck Moore said so and people are afarid to go 64 bit , or is it a more technical thing like power consumption? I think if designed well with todays minuaturised memory circuits a 64 bit CPU could easily compete with a 16 bit CPU (speed , size , power consumption) and seriously out perform it.
>
> If I am missing something , please someone enlighten me.

Yes, I expect you are missing a lot.  What is "more practical" about a 
64 bit processor than a 16 bit processor?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41170

On Friday, August 7, 2015 at 9:44:12 AM UTC-7, mfany...@gmail.com wrote:
> I was just wondering why many Forth CPU's are desinged 
>to be 16 bit whereas a 64 bit CPU would be more practial in today's 
> data processing needs.

You could talk to Sam Falvo.  He seems to know something about
64 bit cores and Forth.

Jason

[toc] | [prev] | [next] | [standalone]

#41185

16-bit is a nice fit for most embedded tasks. If you're into
VHDL you're probably into embedded stuff.

16-bit embedded era is coming to an end I think. 
These days most systems have some sort of  TCP/IP 
connection. With IP in the mix,  security can easily
become the overriding concern in an embedded
design. E.g. The ability to run encryption algorithms
quickly in both directions.  TCP/IP also fits better
in systems with > 64k. A 16-bitter could run out of
horsepower when maintaining a multi port TCP/IP
stack and running its target app. So IMO we're
starting to see the end of 16 bitters. Also the cost
of some 32 bitters means it's not worth considering
16 bits. 

However if you're building a chip in VHDL you'll
probably just go for simplicity. Hence 16 bits. 

[toc] | [prev] | [next] | [standalone]

#41189

On 8/7/2015 7:59 PM, Mark Wills wrote:
> 16-bit is a nice fit for most embedded tasks. If you're into
> VHDL you're probably into embedded stuff.
>
> 16-bit embedded era is coming to an end I think.
> These days most systems have some sort of  TCP/IP
> connection. With IP in the mix,  security can easily
> become the overriding concern in an embedded
> design. E.g. The ability to run encryption algorithms
> quickly in both directions.  TCP/IP also fits better
> in systems with > 64k. A 16-bitter could run out of
> horsepower when maintaining a multi port TCP/IP
> stack and running its target app. So IMO we're
> starting to see the end of 16 bitters. Also the cost
> of some 32 bitters means it's not worth considering
> 16 bits.
>
> However if you're building a chip in VHDL you'll
> probably just go for simplicity. Hence 16 bits.

I'm not sure how the "horsepower" is related to the bit width of a soft 
core processor.  In general, the instruction rate of a processor is 
increased by reducing the bit width of the data path.  A 64 bit 
processor would be significantly slower for an ADD type instruction.  Or 
is this just about the higher data movement rates possible with a wider 
data bus?  Even that would require the peripherals to have wider 
interfaces... and... this means programmed I/O is being used rather than 
DMA which is typically faster and relieves the CPU of this overhead.

As to designing, it really doesn't make much difference if it is 16, 32 
or 64 bits.  That is just a constant in the code and can be changed 
easily as long as it doesn't impact the architecture.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41190

On Fri, 07 Aug 2015 12:44:11 -0400, <mfanyikazi@gmail.com> wrote:

> I was just wondering why many Forth CPU's are desinged to
> be 16 bit whereas a 64 bit CPU would be more practial in
> today's data processing needs.
>
> [...]
>
> If I am missing something , please someone enlighten me.
>

32-bit has some advantages over 16-bit:

1) larger address space
2) bigger integers

32-bit proved to be sufficient for most processing.

There is nothing that I can do on this 64-bit Linux
that I couldn't do on 32-bit Windows 98/SE.

So, what advantage does 64-bit have over 32-bit?

I.e., there is a financial advantage to companies
selling 64-bit processors.


Rod Pemberton

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#41196

sâmbătă, 8 august 2015, 08:38:04 UTC+3, Rod Pemberton a scris:
> On Fri, 07 Aug 2015 12:44:11 -0400, <mfanyikazi@gmail.com> wrote:
> 
> > I was just wondering why many Forth CPU's are desinged to
> > be 16 bit whereas a 64 bit CPU would be more practial in
> > today's data processing needs.
> >
> > [...]
> >
> > If I am missing something , please someone enlighten me.
> >
> 
> 32-bit has some advantages over 16-bit:
> 
> 1) larger address space
> 2) bigger integers
> 
> 32-bit proved to be sufficient for most processing.
> 
Agree.

Although, for embedded systems - microcontrollers - I would go to a 16bit core BUT with 32bit addresses. This is happening in every 8bit micro, using
two registers (a pair) for the addressing.
Also, for the math, when you need the 32bit range, you get it with just two instructions instead of one. The AVR (8bit) core proves that. You just have to have a "with carry" complement instructions (add/adc, sub/sbc, cmp/cpc etc.)

I don't know why it is not done. A microcontroller with 16bit registers and pair addressing would be very nice.

It is a saying that the 16bit doesn't make sense between 8bit and 32bit fight. This is non-sense. The only 16bit problem is the addressing which is indeed not enough. Pair address register and you are done.

[toc] | [prev] | [next] | [standalone]

#41212

Op Fri, 7 Aug 2015 23:42:54 -0700 (PDT) schreef Raimond Dragomir:

> sâmbătă, 8 august 2015, 08:38:04 UTC+3, Rod Pemberton a scris:
>> On Fri, 07 Aug 2015 12:44:11 -0400, <mfanyikazi@gmail.com> wrote:
>> 
>>> I was just wondering why many Forth CPU's are desinged to
>>> be 16 bit whereas a 64 bit CPU would be more practial in
>>> today's data processing needs.
>>>
>>> [...]
>>>
>>> If I am missing something , please someone enlighten me.
>>>
>> 
>> 32-bit has some advantages over 16-bit:
>> 
>> 1) larger address space
>> 2) bigger integers
>> 
>> 32-bit proved to be sufficient for most processing.
>> 
> Agree.
> 
> Although, for embedded systems - microcontrollers - I would
> go to a 16bit core BUT with 32bit addresses. This is happening
> in every 8bit micro, using two registers (a pair) for the addressing.
> Also, for the math, when you need the 32bit range, you get it
> with just two instructions instead of one. The AVR (8bit) core
> proves that. You just have to have a "with carry" complement
> instructions (add/adc, sub/sbc, cmp/cpc etc.)
> 
> I don't know why it is not done. A microcontroller with 16bit
> registers and pair addressing would be very nice.
Did you look for the Renesas M16 series?
20 bit address and 16 bit registes. There is a ciforth version for them.

Please use shorter lines.

groet Coos

[toc] | [prev] | [next] | [standalone]

#41202

On 8/7/15 6:44 AM, mfanyikazi@gmail.com wrote:
> I was just wondering why many Forth CPU's are desinged to be 16 bit whereas a 64 bit CPU would be more practial in today's data processing needs.
>
> I think even when working with sensor data; a 64 bit Forth CPU would be more practical than a 16 bit CPU. Is it because Chuck Moore said so and people are afarid to go 64 bit , or is it a more technical thing like power consumption? I think if designed well with todays minuaturised memory circuits a 64 bit CPU could easily compete with a 16 bit CPU (speed , size , power consumption) and seriously out perform it.
>
> If I am missing something , please someone enlighten me.
>

What you're missing is the most important question of all: what are you 
going to use it for?

FORTH, Inc. has developed many, many applications in 16-bit systems, 
without any memory problems: multitasking, multi user applications, 
controlling equipment, taking data, etc. We have also worked on many 
applications that seriously benefited from 32-bit address space because 
of the need to store large amounts of data, for example -- since Forth 
programs tend to be extremely small compared with programs written in 
other languages, the need for online data storage drives the address 
space requirement. Quite frankly, none of our customers have come to us 
with projects that require 64-bit addressing capability, although no 
doubt they'll come.

However, you're asking specifically about Forth CPUs. As far as I know, 
they have all been targeted at embedded applications, not general data 
processing applications. Developers of embedded computer projects are 
generally looking at high volumes of products, so the cost of memory and 
address space is a relevant consideration and the need for vast amounts 
of memory is rarely a driving issue. Forth CPUs have had a variety of 
cell widths: 16-bit, 18-bit, 24-bit (that I know of). They have all been 
designed for a target market, and sized appropriately. Most programs in 
today's market that need really vast amounts of data storage space run 
on PCs or similar.

Cheers,
Elizabeth

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

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

[toc] | [prev] | [next] | [standalone]

#41203

On Friday, August 7, 2015 at 6:44:12 PM UTC+2, mfany...@gmail.com wrote:
> I was just wondering why many Forth CPU's are desinged 
> to be 16 bit whereas a 64 bit CPU would be more practial 
> in today's data processing needs.

Search for "SOD64 - a 64bit Stack Oriented Design Processor"

-marcel

[toc] | [prev] | [next] | [standalone]

#41205

On 07/08/2015 17:44, mfanyikazi@gmail.com wrote:
> I was just wondering why many Forth CPU's are desinged to be 16 bit whereas a 64 bit CPU would be more practial in today's data processing needs.
>
> I think even when working with sensor data; a 64 bit Forth CPU would be more practical than a 16 bit CPU. Is it because Chuck Moore said so and people are afarid to go 64 bit , or is it a more technical thing like power consumption? I think if designed well with todays minuaturised memory circuits a 64 bit CPU could easily compete with a 16 bit CPU (speed , size , power consumption) and seriously out perform it.
>
> If I am missing something , please someone enlighten me.
>

I've never really understood why the number of bits has to be a power of 
2. Early computers had all sorts of strange word widths. The first 
computer I worked with was 24 bits with 18 bit addresses.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#41209

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>I've never really understood why the number of bits has to be a power of 
>2. Early computers had all sorts of strange word widths. The first 
>computer I worked with was 24 bits with 18 bit addresses.

If you want a byte-addressed machine, then the following should hold:

Bits-per-word = 2^n * Bits-per-byte

That makes address computations easier.  Now, with the compiuter
industry having standardized the 8-bit byte, this results in
power-of-two word widths.

Of course, if you do a word-addressed machine like the early
computers, you can use pretty much any word width.  E.g., Chuck Moore
used IIRC 20 bits on the MuP21, and 18 bits on his more recent work.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41218

On Sat, 08 Aug 2015 06:27:51 -0400, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:

> I've never really understood why the number of bits has to be a
> power of 2.

They don't have to be.  E.g., see this link:

https://en.wikipedia.org/wiki/Ternary_computer

It's just that most electronic circuits are designed for binary logic
for computing.  They don't use ternary logic.  This should not be
confused with tri-state logic.  The latter has 3 electrical levels,
but only two are used for representing digits, i.e., binary logic.


Rod Pemberton
P.S. Deja Vu, I'm sure I replied to someone on this before...

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#41223

On Sunday, August 9, 2015 at 10:24:37 AM UTC+3, Rod Pemberton wrote:
> On Sat, 08 Aug 2015 06:27:51 -0400, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> 
> > I've never really understood why the number of bits has to be a
> > power of 2.
> 
> They don't have to be.  E.g., see this link:
> 
> https://en.wikipedia.org/wiki/Ternary_computer
> 
> It's just that most electronic circuits are designed for binary logic
> for computing.  They don't use ternary logic.  This should not be
> confused with tri-state logic.  The latter has 3 electrical levels,
> but only two are used for representing digits, i.e., binary logic.
> 
> 
> Rod Pemberton
> P.S. Deja Vu, I'm sure I replied to someone on this before...
> 
> -- 
> Scientists now say we'll experience a mini-ice in 2030.
> So, I guess we need more global warming today ...

Hence the three laws of robotics can naturally be represented at the lowest laevel of data abastraction :)

[toc] | [prev] | [next] | [standalone]

#41228

On 8/9/2015 3:24 AM, Rod Pemberton wrote:
> On Sat, 08 Aug 2015 06:27:51 -0400, Gerry Jackson
> <gerry@jackson9000.fsnet.co.uk> wrote:
>
>> I've never really understood why the number of bits has to be a
>> power of 2.
>
> They don't have to be.  E.g., see this link:
>
> https://en.wikipedia.org/wiki/Ternary_computer
>
> It's just that most electronic circuits are designed for binary logic
> for computing.  They don't use ternary logic.  This should not be
> confused with tri-state logic.  The latter has 3 electrical levels,
> but only two are used for representing digits, i.e., binary logic.

I took a class in college about logic with more than two states.  It was 
about the theory, the math required to generalize Boolean logic to 
multiple states, Boolean logic being a subset of Post algebra.  The 
details of how to implement the logic aren't so hard and have been used 
in many chips for a long time.  I believe one of the relatively early 
Intel chips used three states for the microcode, not sure what chip this 
was, perhaps one of the floating point chips.

Many flash devices use four levels, doubling the density which seems to 
work very well.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#41215

пятница, 7 августа 2015 г., 19:44:12 UTC+3 пользователь mfany...@gmail.com написал:
> I was just wondering why many Forth CPU's are desinged to be 16 bit whereas a 64 bit CPU would be more practial in today's data processing needs.
> 
> I think even when working with sensor data; a 64 bit Forth CPU would be more practical than a 16 bit CPU. Is it because Chuck Moore said so and people are afarid to go 64 bit , or is it a more technical thing like power consumption? I think if designed well with todays minuaturised memory circuits a 64 bit CPU could easily compete with a 16 bit CPU (speed , size , power consumption) and seriously out perform it.
> 
> If I am missing something , please someone enlighten me.

If CPU has wider data than needed, too wide literals will consume more memory. If CPU has too small datawidth, required operations must be emulated, this leads both to performance and memory losses.

On-chip memory size is still a problem (for both FPGA and ASIC). There are not enough memory... it seems, this lasts forever :) Forth-CPU may be designed with 8-bit code width, and this is not depend on data width, except of literals.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web