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 1 of 2  [1] 2  Next page →

#15979 — Nice little Forth article

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

Thanks to JohnnyBritish.

[toc] | [next] | [standalone]

#15983

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

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

#15984

"Mark Wills" <forthfreak@gmail.com> wrote in message
news:92c2886f-bae2-41b6-b7a2-36dce5b95ef5@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

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

#15986

On 10/6/12 11:56 AM, Rod Pemberton wrote:
> "Mark Wills" <forthfreak@gmail.com> wrote in message
> news:92c2886f-bae2-41b6-b7a2-36dce5b95ef5@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/

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

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

#15990

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.

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

#15995

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-b7a2-36dce5b95ef5@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

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.

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

#16027

"Mark Wills" <forthfreak@gmail.com> wrote in message
news:9ddbe7ca-576a-4e4b-b128-6e55a71d2816@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-b7a2-36dce5b95ef5@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

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

#16177

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.

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

#15994

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.

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

#16024

"Hugh Aguilar"  wrote in message
> news:1c972ea2-59db-4cbb-8abf-6bb52ed5d589@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

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

#16033

"Bill Leary" <Bill_Leary@msn.com> wrote in message
news:qoCdnbHXTbsQbuzNnZ2dnUVZ_tOdnZ2d@giganews.com...
> "Hugh Aguilar"  wrote in message
> > news:1c972ea2-59db-4cbb-8abf-6bb52ed5d589@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

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

#16093

"Rod Pemberton"  wrote in message news:k4t507$nam$1@speranza.aioe.org...
> "Bill Leary" <Bill_Leary@msn.com> wrote in message
> news:qoCdnbHXTbsQbuzNnZ2dnUVZ_tOdnZ2d@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

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

#16178

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

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

#16187

"Hugh Aguilar"  wrote in message 
news:8328d5fb-cb54-4966-b88f-3d54d17e1634@q7g2000pbj.googlegroups.com...
> 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.

    - Bill 

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

#16197

On 10/11/12 2:28 AM, Bill Leary wrote:
> "Hugh Aguilar"  wrote in message
> news:8328d5fb-cb54-4966-b88f-3d54d17e1634@q7g2000pbj.googlegroups.com...
>> 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.

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

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

#16260

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 :)

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

#16264

"Ed" <invalid@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.

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

#16265

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
 

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

#16267

On Oct 14, 5:51 pm, Howerd <howe...@yahoo.co.uk> wrote:
> 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!

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

#16269

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/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web