-- ==================================================
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."
==================================================
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.
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."
==================================================
> 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.
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.
"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!
> 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.
> > 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.
> > 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.
> 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.
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?
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.
On Oct 7, 2:26 pm, "Bill Leary" <Bill_Le...@msn.com> wrote:
> "Hugh Aguilar" wrote in message
> >news:1c972ea2-59db-4cbb-8abf-6bb52ed5d589@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."
> On Oct 7, 2:26 pm, "Bill Leary" <Bill_Le...@msn.com> wrote:
>> "Hugh Aguilar" wrote in message
>> >news:1c972ea2-59db-4cbb-8abf-6bb52ed5d589@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."
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.
>>> > 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."
> 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.
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.
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."
==================================================
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 :)
"Ed" <inva...@nospam.com> wrote:
> 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 :)
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.
On Sunday, October 14, 2012 3:42:14 PM UTC+2, Anonymous wrote:
> "Ed" <inv....@nospam.com> wrote:
> > 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 :)
> 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.
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".
> On Sunday, October 14, 2012 3:42:14 PM UTC+2, Anonymous wrote:
> > "Ed" <inv....@nospam.com> wrote:
> > > 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 :)
> > 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.
> 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
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!
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/
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).
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Bernd Paysan <bernd.pay...@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.
> 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.
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.
