Nice little Forth article

[Mark Wills]

http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html

Thanks to JohnnyBritish.

[Elizabeth D. Rather]

On 10/6/12 8:42 AM, Mark Wills wrote:
> http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html
>
> Thanks to JohnnyBritish.
>

Yes, that is a nice article. Thanks!

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."
==================================================

[Rod Pemberton]

"Mark Wills" <forth...@gmail.com> wrote in message
news:92c2886f-bae2-41b6...@a7g2000yqo.googlegroups.com...

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

Why Forth and BASIC no longer matter for ARM:
http://hackaday.com/2012/10/05/a-javascript-interpreter-for-arm-micros/


Rod Pemberton

[Elizabeth D. Rather]

I'll be interested in hearing how much of the 128Kb Flash and 8Kb RAM is
available for user programs once his Java interpreter is running, not to
mention how its performance compares.

[Hugh Aguilar]

On Oct 6, 3:41 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 10/6/12 11:56 AM, Rod Pemberton wrote:
> > Why Forth and BASIC no longer matter for ARM:
> >http://hackaday.com/2012/10/05/a-javascript-interpreter-for-arm-micros/
>
> I'll be interested in hearing how much of the 128Kb Flash and 8Kb RAM is
> available for user programs once his Java interpreter is running, not to
> mention how its performance compares.

Java and JavaScript are different languages.

[Hugh Aguilar]

On Oct 6, 11:42 am, Mark Wills <forthfr...@gmail.com> wrote:
> http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html
>
> Thanks to JohnnyBritish.

His point is that Forth is better for small low-power systems than C
is. This helps when you are doing the project as a hobby and your
"copious free time" is limited. Forth-vs-C is not an issue with
commercial projects because they are going to be written in assembly-
language, and they will use a much smaller processor than Forth or C
could run on (typically 128 bytes of data memory and 2K of code
memory). Even though the programming is done in assembly rather than a
high-level language, the cost of programming will still be only a tiny
fraction of the total cost of the project. The programming may get
done by the electrical engineer, in which case the cost of programming
is $0 because no programmer was hired. This was true in the 1990s and
it is still true today.

Computer programmers are not important people --- their opinion on
Forth-vs-C doesn't matter to anybody.

If the opinion of computer programmers mattered to anybody, processors
such as the PIC16 and the 8051 would not have been popular --- those
things aren't easy to program --- it was the electrical engineers'
opinion that mattered.

[Mark Wills]

On Oct 6, 10:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cmm>
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message

WTF??

"Gordon] figured it’s not 1980 anymore, and interpreters for these
relatively low-level languages aren’t a good fit with the
microcontrollers of today. To solve this problem, he created Espruino,
a JavaScript interpreter for the new batch of ARM development boards
that have been cropping up."

So... A low-level, efficient, resource light, CPU light language is
"not a good fit" (with no justification given at all) and he replaces
it with.... JavaScript?

Are you f***ing kidding me?

Why Forth and BASIC no longer matter for ARM?

HA! Hilarious! I'm not sure they *ever* mattered for ARM, but if you
think JavaScript (LMAO) is the saviour then I have some beach property
in Fukushima to sell you!

Thanks for a good laugh on a Sunday morning.

[Bill Leary]

"Hugh Aguilar" wrote in message
> news:1c972ea2-59db-4cbb...@g7g2000pbh.googlegroups.com...

>
> On Oct 6, 11:42 am, Mark Wills <forthfr...@gmail.com> wrote:
>> http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html
>>
>> Thanks to JohnnyBritish.
>
> His point is that Forth is better for small low-power systems than C
> is. This helps when you are doing the project as a hobby and your
> "copious free time" is limited. Forth-vs-C is not an issue with
> commercial projects because they are going to be written in assembly-
> language, and they will use a much smaller processor than Forth or C
> could run on (typically 128 bytes of data memory and 2K of code
> memory). Even though the programming is done in assembly rather than a
> high-level language, the cost of programming will still be only a tiny
> fraction of the total cost of the project. The programming may get
> done by the electrical engineer, in which case the cost of programming
> is $0 because no programmer was hired.

You don't pay the EE for his or her time spent programming?

> This was true in the 1990s and it is still true today.

I wonder. I've been doing embedded work since the late 70's. In all that
time, on all those projects, the programming (except for programmable logic)
was done my programmers. Early on in assembler, later most of it in an
embedded dialect of C or PL/M. I've known EEs who could program, but I
don't recall one who wouldn't defer to a full time programmer, if that
programmer was hardware knowledgeable.

> Computer programmers are not important people --- their opinion on
> Forth-vs-C doesn't matter to anybody.

Hmmm.

> If the opinion of computer programmers mattered to anybody, processors
> such as the PIC16 and the 8051 would not have been popular --- those
> things aren't easy to program --- it was the electrical engineers'
> opinion that mattered.

I never worked with a PIC16. I've done a fair amount of work on several
8051 flavors and didn't find them particularly difficult to program.

- Bill

[Rod Pemberton]

"Mark Wills" <forth...@gmail.com> wrote in message

news:9ddbe7ca-576a-4e4b...@o7g2000yqb.googlegroups.com...

> On Oct 6, 10:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cmm>
> wrote:
> > "Mark Wills" <forthfr...@gmail.com> wrote in message
news:92c2886f-bae2-41b6...@a7g2000yqo.googlegroups.com...

...

> > >[link]
> >
> > > Thanks to JohnnyBritish.
> >
> > Why Forth and BASIC no longer matter for ARM: [link]

> >
>
> WTF??
>
> "Gordon figured it's not 1980 anymore, and interpreters for these
> relatively low-level languages aren't a good fit with the
> microcontrollers of today. To solve this problem, he created Espruino,
> a JavaScript interpreter for the new batch of ARM development boards
> that have been cropping up."
>
> So... A low-level, efficient, resource light, CPU light language is
> "not a good fit" (with no justification given at all) and he replaces
> it with.... JavaScript?
>

Yes, no justification given at all ...

Ok, we've got one guy here who is awake!

I was curious too as for more detail on what isn't a good fit. It might've
been he just didn't like Forth or BASIC.

> Are you f***ing kidding me?

I posted a link. It has a link for his website. He has video too. It
seems to function. So, no, I wasn't ... :-)

> Why Forth and BASIC no longer matter for ARM?

Who uses them? Who'll use them now? ;-) That was the humorous point.

I do think it's novel that he chose an existing language. Typically, these
guys create their own language when they don't want BASIC or Forth. Of
course, no one uses their language.

> HA! Hilarious! I'm not sure they *ever* mattered for ARM, but if you
> think JavaScript (LMAO) is the saviour then I have some beach property
> in Fukushima to sell you!

Well, the video shows a bunch of microcontroller specific code and what I'd
call minimal C. And, he hasn't released any source code. So, no one has
any idea of how much "Javascript" is actually present in his Javascript. As

far as anyone knows, it might be an ITC or DTC Forth with a modified parser
(outer interpreter). He does have a : (colon) at the start of each line in
the video, but I can't tell if that is indicative of Forth or just a prompt.

I haven't done much of anything in JavaScript. I have worked on one app by
someone else. From what little I have used it, it's very C like but with
automatic allocation and freeing of variables, more like an interpreted
BASIC.


Rod Pemberton

[Rod Pemberton]

"Bill Leary" <Bill_...@msn.com> wrote in message
news:qoCdnbHXTbsQbuzN...@giganews.com...

> "Hugh Aguilar" wrote in message
> > news:1c972ea2-59db-4cbb...@g7g2000pbh.googlegroups.com...
> > On Oct 6, 11:42 am, Mark Wills <forthfr...@gmail.com> wrote:
http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html
> >>
> >> Thanks to JohnnyBritish.
> >
> > His point is that Forth is better for small low-power systems than C
> > is. This helps when you are doing the project as a hobby and your
> > "copious free time" is limited. Forth-vs-C is not an issue with
> > commercial projects because they are going to be written in assembly-
> > language, and they will use a much smaller processor than Forth or C
> > could run on (typically 128 bytes of data memory and 2K of code
> > memory). Even though the programming is done in assembly rather than a
> > high-level language, the cost of programming will still be only a tiny
> > fraction of the total cost of the project. The programming may get
> > done by the electrical engineer, in which case the cost of programming
> > is $0 because no programmer was hired.
>
> You don't pay the EE for his or her time spent programming?
>

No, I think the EE still gets paid in that scenario. It's just that his/her
pay for progamming isn't part of the "cost of programming" for the project
according to Hugh's accounting methods, or perhaps those of a prior
employer.

;-)

> I wonder. I've been doing embedded work since the late 70's. In all that
> time, on all those projects, the programming (except for programmable
> logic) was done my programmers. Early on in assembler, later most of it
> in an embedded dialect of C or PL/M. I've known EEs who could program,
> but I don't recall one who wouldn't defer to a full time programmer, if
> that programmer was hardware knowledgeable.

My experience is that EEs are good with hardware and CSs aren't so good. The
concepts needed for programming hardware, mostly developed by EEs, elude CSs
somewhat. Once a CS major has to start thinking about electricity,
currents, voltages, or even things like endianness or data bus size, you've
lost them.


Rod Pemberton

[Bill Leary]

"Rod Pemberton" wrote in message news:k4t507$nam$1...@speranza.aioe.org...

> "Bill Leary" <Bill_...@msn.com> wrote in message
> news:qoCdnbHXTbsQbuzN...@giganews.com...

> ((..older material deleted..))

>> You don't pay the EE for his or her time spent programming?
>>
> No, I think the EE still gets paid in that scenario. It's just that
> his/her
> pay for progamming isn't part of the "cost of programming" for the
> project according to Hugh's accounting methods, or perhaps those
> of a prior employer.

I meant the comment somewhat sarcastically, but I suspect you are correct.

>> I wonder. I've been doing embedded work since the late 70's. In
>> all that time, on all those projects, the programming (except for
>> programmable logic) was done my programmers. Early on in
>> assembler, later most of it in an embedded dialect of C or PL/M.
>> I've known EEs who could program, but I don't recall one who
>> wouldn't defer to a full time programmer, if that programmer
>> was hardware knowledgeable.
>
> My experience is that EEs are good with hardware and CSs aren't
> so good.

My experience too.

> The concepts needed for programming hardware, mostly developed
> by EEs, elude CSs somewhat. Once a CS major has to start thinking
> about electricity, currents, voltages, or even things like endianness
> or data bus size, you've lost them.

Agreed. Which is why I included the "...if that programmer was hardware
knowledgeable." condition in my comment.

I recall an incident where the "real" programmers were demanding the
hardware guys expand the EEPROM on the machine by eight times because they
couldn't fit their communications stack on it to boot the machine. There
(1) wasn't room on the board for that and (2) wasn't money in the budget for
the parts and (3) wasn't time in the schedule. Note that none of this was
the HW guys fault. The SW guys decided, well after the boards were being
built, to change their approach to booting the machines from something very
simple to something rather complicated. In the meeting where they argued
about this, I made the comment "It's just bits on a wire. Parse the ones
you want and ignore the rest." The gave me a blank stare. It ended up they
dared me to do it. I did. With an oscilloscope, in assembler and C, and
within the space-and-time budget. But then, I wasn't a "real" programmer, by
their definition, because I did understand (as you put it) "...electricity,
currents, voltages ... endianness ... data bus size..."

Going back to the original point, I wonder if the places Hugh worked simply
didn't hire programmers who were hardware knowledgeable, but the places I
worked did. Changes ones perspective on the issue a bit.

- Bill

- Bill

[Ed]

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?

[Hugh Aguilar]

On Oct 6, 11:54 pm, Mark Wills <forthfr...@gmail.com> wrote:
> So... A low-level, efficient, resource light, CPU light language is
> "not a good fit" (with no justification given at all) and he replaces
> it with.... JavaScript?
>
> Are you f***ing kidding me?

Well Mark, it could have been worse --- he could have chosen Lisp
itself (JavaScript is one of the many many Lisp-derivatives) --- I
think Lisp and its spawn are great languages, but not for micro-
controllers.

[Hugh Aguilar]

On Oct 7, 2:26 pm, "Bill Leary" <Bill_Le...@msn.com> wrote:
> "Hugh Aguilar"  wrote in message
> >news:1c972ea2-59db-4cbb...@g7g2000pbh.googlegroups.com...

> > If the opinion of computer programmers mattered to anybody, processors
> > such as the PIC16 and the 8051 would not have been popular --- those
> > things aren't easy to program --- it was the electrical engineers'
> > opinion that mattered.
>
> I never worked with a PIC16.  I've done a fair amount of work on several
> 8051 flavors and didn't find them particularly difficult to program.

The 8051, PIC16, etc., don't support high-level languages very well
(both Forth and C are incomplete implementations, and are grossly
inefficient) --- and programmers prefer to use high-level languages
rather than assembly language --- and the electrical engineers say:
"Grow a spine and program in assembly language; we are not going to
use a big expensive processor just so you can program in a high-level
language when a small inexpensive processor is capable of doing the
job."

[Bill Leary]

"Hugh Aguilar" wrote in message

news:8328d5fb-cb54-4966...@q7g2000pbj.googlegroups.com...

I've programmed 8051's (and derivatives) in C and assembler. Some of the
C's were woefully inefficient. A very few, optimized for the 8051 (and
thus, technically, only "C-like" languages) did a pretty good job. Either
way, even in assembler, I didn't find the 8051 to be all that difficult to
work with. I'm wondering what sorts of programmers you've worked with. A
manager should not be putting a programmer who can't think in terms of
registers and hardware to work on a platform where one must think of such
things to do the job properly.

- Bill

[Elizabeth D. Rather]

I've never worked with a member of the PIC family, but we have done
many, many projects with 8051s, some of them quite complex. SwiftX
generates pretty good native 8051 code, and supports a very efficient
multitasker. Engineers don't generally design with 8051s for blazing
speed, but for low unit costs, and the ease of programming them with
Forth (preferably in a reasonable, native-code implementation) is a real
plus.

[Ed]

Bill Leary wrote:
> "Hugh Aguilar" wrote in message

> ...

> > The 8051, PIC16, etc., don't support high-level languages very well
> > (both Forth and C are incomplete implementations, and are grossly
> > inefficient) --- and programmers prefer to use high-level languages
> > rather than assembly language --- and the electrical engineers say:
> > "Grow a spine and program in assembly language; we are not going to
> > use a big expensive processor just so you can program in a high-level
> > language when a small inexpensive processor is capable of doing the
> > job."
>
> I've programmed 8051's (and derivatives) in C and assembler. Some of the
> C's were woefully inefficient. A very few, optimized for the 8051 (and
> thus, technically, only "C-like" languages) did a pretty good job. Either
> way, even in assembler, I didn't find the 8051 to be all that difficult to

> work with. ...

Hugh's point - that 8051's are ill-suited to HLL's - is hard to argue with.
I was going to say Intel likely no such intent when they designed the chip
... but then I recalled they did release that version with interpreted BASIC
in masked rom. So what can we conclude? Anything that makes one
a dollar can't be all bad :)

[Anonymous]

There's another thread going on in comp.arch on Intel's non-designs. This
just backs up what many of us have been saying that Intel's successes are
marketing successes; they really can't design anything good.

[Howerd]

On Sunday, October 14, 2012 3:42:14 PM UTC+2, Anonymous wrote:

Hi Anonymous, Ed and Hugh,

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.
Likewise the 80x86 family, while limited by having to be backward compatible back to 8 bits, is very good at producing compact programs.

So these Intel processors may not be what is required for today's programs, but I have always had the highest respect for the level of thought and detailed design that has gone into them. So I would not agree that Intel's success is just down to marketing.

There is a difference between saying that processor designs that originated in the 70's (or earlier) may not optimal for today's programs, and saying that
"[Intel] really can't design anything good".

Just my tuppence worth :-)

Best regards,
Howerd

[Mark Wills]

I'm sure they could design something good, if they weren't shackled to
the requirement to be able to run code that was written in 1975!

[Bernd Paysan]

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/

[Bernd Paysan]

Mark Wills wrote:
> I'm sure they could design something good, if they weren't shackled to
> the requirement to be able to run code that was written in 1975!

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. Fred Brooks
calls that "the second system effect". You have a working system, which
is somehow limited and has accumulated cruft, but it is working. You
now decide to start over again, and implement everything you wished to
implement, but didn't have the time or the compatibility constraints
prohibited it. Your new design is complete and utter crap, because you
forget to keep it simple (something you did with the initial design by
accident due to the constraints you had - e.g. a limited transistor
budget).

[Paul Rubin]

Bernd Paysan <bernd....@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.

[rickman]

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

[Sara Cruz]

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.

[Hugh Aguilar]

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!

[Brad Eckert]

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.

[Andrew Haley]

Sara Cruz <iluv...@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.

[Bernd Paysan]

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.

[Hugh Aguilar]

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.

[rickman]

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