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

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

Nice little Forth article

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

Contents

  Nice little Forth article Mark Wills <forthfreak@gmail.com> - 2012-10-06 11:42 -0700
    Re: Nice little Forth article "Elizabeth D. Rather" <erather@forth.com> - 2012-10-06 10:23 -1000
    Re: Nice little Forth article "Rod Pemberton" <do_not_have@notemailnotz.cmm> - 2012-10-06 17:56 -0400
      Re: Nice little Forth article "Elizabeth D. Rather" <erather@forth.com> - 2012-10-06 12:41 -1000
        Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-06 18:10 -0700
      Re: Nice little Forth article Mark Wills <forthfreak@gmail.com> - 2012-10-06 23:54 -0700
        Re: Nice little Forth article "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-07 19:14 -0400
        Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-10 19:19 -0700
    Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-06 20:30 -0700
      Re: Nice little Forth article "Bill Leary" <Bill_Leary@msn.com> - 2012-10-07 17:26 -0400
        Re: Nice little Forth article "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-07 20:02 -0400
          Re: Nice little Forth article "Bill Leary" <Bill_Leary@msn.com> - 2012-10-09 08:35 -0400
        Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-10 19:27 -0700
          Re: Nice little Forth article "Bill Leary" <Bill_Leary@msn.com> - 2012-10-11 08:28 -0400
            Re: Nice little Forth article "Elizabeth D. Rather" <erather@forth.com> - 2012-10-11 08:06 -1000
            Re: Nice little Forth article "Ed" <invalid@nospam.com> - 2012-10-14 16:17 +1000
              Re: Nice little Forth article Anonymous <nobody@remailer.paranoici.org> - 2012-10-14 13:41 +0000
                Re: Nice little Forth article Howerd <howerdo@yahoo.co.uk> - 2012-10-14 09:51 -0700
                  Re: Nice little Forth article Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-14 10:41 -0700
                    Re: Nice little Forth article Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 22:28 +0200
                      Re: Nice little Forth article Paul Rubin <no.email@nospam.invalid> - 2012-10-14 13:39 -0700
                  Re: Nice little Forth article Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 19:42 +0200
                    Re: Nice little Forth article rickman <gnuarm@gmail.com> - 2012-10-14 20:02 -0400
                    Re: Nice little Forth article Sara Cruz <iluv2hugg@gmail.com> - 2012-10-17 19:45 -0700
                      Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-17 20:20 -0700
                      Re: Nice little Forth article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-18 11:39 -0500
                      Re: Nice little Forth article Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-18 18:53 +0200
                        Re: Nice little Forth article Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:58 -0700
                          Re: Nice little Forth article rickman <gnuarm@gmail.com> - 2012-10-20 18:08 -0400
    Re: Nice little Forth article "Ed" <invalid@nospam.com> - 2012-10-10 08:23 +1000
      Re: Nice little Forth article Brad Eckert <hwfwguy@gmail.com> - 2012-10-18 09:15 -0700

Page 2 of 2 — ← Prev page 1 [2]

#16270

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Whenever Intel's designer were free to design something that wasn't 
> backward compatible, from i432 over i860 to IA64, they produced 
> something hellish complicated and/or difficult to program.  

People told me good things about the i960, though I never programmed it
myself.  It was rather popular in embedded systems in areas where ARMs
etc. are now used today.

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

#16268

Howerd wrote:
> I have been using 8051's since the early 80's and I have grown to love
> them. I think that the way the address space is divided into external,
> internal and bits is just about right for the types of applications
> that 8051's are targeted at.

I don't really see a point why you expose something trivial like an 
address decoder to the user and have different instructions (with 
different encodings and even different pointer registers) for the 
different parts of the address space.

At the time I wrote the b16, I was working on a project where our 
customer had insisted on an 8051 as embedded CPU - the reason was legacy 
code which they didn't use later... and familiarity with the device, 
which was the same rubbish, as they outsourced the programming of the 
new firmware...

I had written some test programs with the 8051, and it made me thick.  
It was a major motivator to write something better.

> Likewise the 80x86 family, while limited
> by having to be backward compatible back to 8 bits, is very good at
> producing compact programs.

It was only source-code backward compatible.  Anything would have done.  
IMHO, the main reason why x86 was a success is that it was a "plan B", 
and they had only two people sitting together for three weeks to design 
the ISA.  They didn't have enough resources to screw up completely.  The 
386 extension wasn't too bad, it made the ISA more regular; though the 
incredible amount of stupid and unusable bloat with the 286 segmentation 
did have to go in.  And the x64 extension, which finally gave us a sane 
number of registers, wasn't even made by them.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#16275

On 10/14/2012 1:42 PM, Bernd Paysan wrote:
> Howerd wrote:
> It was only source-code backward compatible.  Anything would have done.

I believe you mean at the assembly language source level.  That was/is a 
big deal to many!


> IMHO, the main reason why x86 was a success is that it was a "plan B",
> and they had only two people sitting together for three weeks to design
> the ISA.  They didn't have enough resources to screw up completely.

At the top of my gnuarm.com web page (not designed by me) is the quote,

"Steve is one of the brightest guys I've ever worked with - brilliant; 
but when we decided to do a microprocessor on our own, I made two great 
decisions - I gave them [Steve Furber and Sophie Wilson] two things 
which National, Intel and Motorola had never given their design teams: 
the first was no money; the second was no people. The only way they 
could do it was to keep it really simple." -- Hermann Hauser

This is about the ARM.  Limited resources is not an impediment to a good 
design, nor is it a guarantee.

The x86 is the success that everyone loves to hate.  I'm fairly 
agnostic, but I avoid PICs and the 8051, not because they are terrible, 
but because I want to learn other things than the oddities of using them.

Rick

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

#16420

On Oct 14, 10:42 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Howerd wrote:
> > I have been using 8051's since the early 80's and I have grown to love
> > them. I think that the way the address space is divided into external,
> > internal and bits is just about right for the types of applications
> > that 8051's are targeted at.
>
> I don't really see a point why you expose something trivial like an
> address decoder to the user and have different instructions (with
> different encodings and even different pointer registers) for the
> different parts of the address space.

Because it significantly reduces code size.

Other processors, such as the 6805 and 6808 etc., are designed to
address 64K of memory. If you only have a small amount of memory
however, then you waste a lot of memory and time messing around with
16-bit (2-byte) addresses when an 8-bit (1-byte) address would do.

The clever thing about the 8051 is that it could address more than 256
memory locations, using only 1-byte addresses --- this was because the
addressing mode determined which memory bank was being used.

I agree with Howerd that the 8051 was an awesome design "for the types
of applications that 8051's are targeted at." When you are programming
in assembly language, and you have a chip with a small amount of on-
chip memory, then the 8051 was (actually, is) a good design. The 8051
only became a problem when it got drafted into tasks that were too big
for it, such as supporting high-level languages and large memories.

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

#16421

On Oct 17, 7:45 pm, Sara Cruz <iluv2h...@gmail.com> wrote:
> On Oct 14, 10:42 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > Howerd wrote:
> > > I have been using 8051's since the early 80's and I have grown to love
> > > them. I think that the way the address space is divided into external,
> > > internal and bits is just about right for the types of applications
> > > that 8051's are targeted at.
>
> > I don't really see a point why you expose something trivial like an
> > address decoder to the user and have different instructions (with
> > different encodings and even different pointer registers) for the
> > different parts of the address space.
>
> Because it significantly reduces code size.
>
> Other processors, such as the 6805 and 6808 etc., are designed to
> address 64K of memory. If you only have a small amount of memory
> however, then you waste a lot of memory and time messing around with
> 16-bit (2-byte) addresses when an 8-bit (1-byte) address would do.
>
> The clever thing about the 8051 is that it could address more than 256
> memory locations, using only 1-byte addresses --- this was because the
> addressing mode determined which memory bank was being used.
>
> I agree with Howerd that the 8051 was an awesome design "for the types
> of applications that 8051's are targeted at." When you are programming
> in assembly language, and you have a chip with a small amount of on-
> chip memory, then the 8051 was (actually, is) a good design. The 8051
> only became a problem when it got drafted into tasks that were too big
> for it, such as supporting high-level languages and large memories.

This message is not "Sara Cruz" (whoever that is), but are actually me
--- Hugh Aguilar

I'm at a library using a public computer. Apparently the last person
on the computer logged in and checked the box to stay logged in (the
one that says *don't* check this if on a shared computer). I posted
this message not realizing that I had never logged in under my own
name.

Oops!

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

#16432

Sara Cruz <iluv2hugg@gmail.com> wrote:
> I agree with Howerd that the 8051 was an awesome design "for the types
> of applications that 8051's are targeted at." When you are programming
> in assembly language, and you have a chip with a small amount of on-
> chip memory, then the 8051 was (actually, is) a good design. The 8051
> only became a problem when it got drafted into tasks that were too big
> for it, such as supporting high-level languages and large memories.

The 8051 is a fine Forth target though, and threaded code can make for
very small code sizes; this make the difference betwwen a progarm that
fits and one that doesn't if you only have a small ROM.

Andrew.

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

#16436

Sara Cruz wrote:
> Other processors, such as the 6805 and 6808 etc., are designed to
> address 64K of memory. If you only have a small amount of memory
> however, then you waste a lot of memory and time messing around with
> 16-bit (2-byte) addresses when an 8-bit (1-byte) address would do.

The 6502 had its famous zero-page.  And the b16 has bytes and words as 
literals, so if you like to keep addresses short, you use the byte 
literals (effectively also a zero-page - the memory mapping schemes I 
have used had a fast and small SRAM mapped to 0-FF).  The benefit you 
get from that is that you

a) have a compact encoding for frequently used addresses and
b) you don't have to special-case these addresses, there is only one 
uniform address space.

> The clever thing about the 8051 is that it could address more than 256
> memory locations, using only 1-byte addresses --- this was because the
> addressing mode determined which memory bank was being used.

When I started at Mikron, we had a legacy PIC16 program, which had to 
use bank switching, due to the limits of the PIC16.  The PIC17 program, 
which had longer addresses, but no bank switching, was considerably 
smaller.  Bank switching is not a good idea.

> I agree with Howerd that the 8051 was an awesome design "for the types
> of applications that 8051's are targeted at." When you are programming
> in assembly language, and you have a chip with a small amount of on-
> chip memory, then the 8051 was (actually, is) a good design. The 8051
> only became a problem when it got drafted into tasks that were too big
> for it, such as supporting high-level languages and large memories.

Oh yes, with "large memories", you mean everything beyond 128 Bytes of 
RAM.  The 8051 architecture pretty much matched what was internal (the 
4k ROM+128b RAM); often the 8048 (which couldn't extend the memory) was 
good enough for these tasks, and therefore still remained very popular.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#16511

On Oct 18, 9:53 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> When I started at Mikron, we had a legacy PIC16 program, which had to
> use bank switching, due to the limits of the PIC16.  The PIC17 program,
> which had longer addresses, but no bank switching, was considerably
> smaller.  Bank switching is not a good idea.

I've programmed the PIC16. In my experience, bank-switching works fine
so long as each data structure fits entirely within a bank. If you
have a data-structure, such as array, that requires more than one bank
then the whole thing can be a big mess. The PIC16 banks were typically
plenty big, whereas the PIC14 banks were almost always too small.

The 8086 was another good design. We got to exceed the 64K limitation
of the Z80 etc., but we still got to use 16-bit registers and 16-bit
pointers (unlike with the 68000 in which we had 32-bit registers and
pointers, but a 16-bit data bus). I think that the 8086 would have
been improved if it had had more segment registers --- having only ES
to play with was too limiting --- but it was still pretty good. It was
quite rare for any data-structure, such as an array, to be larger than
64K.

Of course, none of this matters now --- we have 64-bit registers and
gigabytes of memory. Even with micro-controllers, we have 16-bit
registers and now longer have to mess with 8-bit registers at all. We
even have 32-bit micro-controllers, which I never predicted would be
seen.

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

#16522

On 10/19/2012 9:58 PM, Hugh Aguilar wrote:
>
> The 8086 was another good design. We got to exceed the 64K limitation
> of the Z80 etc., but we still got to use 16-bit registers and 16-bit
> pointers (unlike with the 68000 in which we had 32-bit registers and
> pointers, but a 16-bit data bus). I think that the 8086 would have
> been improved if it had had more segment registers --- having only ES
> to play with was too limiting --- but it was still pretty good. It was
> quite rare for any data-structure, such as an array, to be larger than
> 64K.

How were 32 bit registers limiting?  You don't need to use the full 32 
bits.  Memory transfers could be done in 8, 16 or 32 bit sizes so you 
don't waste bandwidth on the bus.  I've never met anyone before who said 
the x86 architecture was better than the MC68000.


> Of course, none of this matters now --- we have 64-bit registers and
> gigabytes of memory. Even with micro-controllers, we have 16-bit
> registers and now longer have to mess with 8-bit registers at all. We
> even have 32-bit micro-controllers, which I never predicted would be
> seen.

I remember the first time I realized that we would someday actually have 
a single chip RAM with 1 billion bits!  I was actually in awe thinking 
about that.  They even could predict when that would be!!!  I still 
can't understand how we continually need more and more of the stuff.

You can have more food than you can eat, more money than you know how to 
spend and more women than are good for your soul, but you can never have 
too many friends, no one ever lives long enough and you will never have 
enough RAM in your computer!

Rick

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

#16151

Mark Wills wrote:
> http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html
>
> Thanks to JohnnyBritish.

It is a nice article but ...

There was a vendor A.M. Research that specialized in low-cost Forth
systems for exactly such applications.  That vendor is no longer in
business.  If "forth-still-matters" would such vendors not only exist but
thrive?

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

#16430

On Tuesday, October 9, 2012 3:23:49 PM UTC-7, Ed wrote:
> There was a vendor A.M. Research that specialized in low-cost Forth
> systems for exactly such applications.  That vendor is no longer in
> business.  If "forth-still-matters" would such vendors not only exist but
> thrive?

Forth vendors survive by using Forth to write applications. Selling tools doesn't pay the bills because the market is too small. Improvements to the tools happen mostly because the vendors are using them to do real jobs. 

The problem is that most people are lazy. They eat junk food instead of healthy because everyone else does it. Why would choice of programming language deviate from the prevailing psychology? The cultures we are born into, because of the way power structures are set up, teach us from a young age to follow the herd.

Forth has persisted as long as it has, in spite of being the industry's red headed stepchild, because its technical merits.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web