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

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

Integer cosine function

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

Contents

  Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-16 07:35 -0800
    Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 13:57 +0200
      Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-17 09:40 -0600
        Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-17 07:51 -1000
          Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 19:06 +0200
            Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-18 14:46 +0000
            Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 20:01 +0100
              Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-19 21:34 +0200
                Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 21:46 +0100
              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-19 15:55 -0800
                Re: Integer cosine function Coos Haak <chforth@hccnet.nl> - 2013-02-21 00:59 +0100
          Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-18 09:19 -0800
            Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-18 14:27 -0500
            Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-18 20:53 +0100
              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-18 19:10 -0800
                Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-19 13:13 +0100
                Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-19 23:04 -0500
              Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-20 10:00 -0800
                Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:04 +0100
                  Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-21 19:03 -0500
                    Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 02:45 +0100
                      Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:32 -0800
                        Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 16:01 +0100
                      Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 22:07 -0800
                        Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 10:27 -0500
                  Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 03:59 -0600
                    Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:30 -0800
                    Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 15:56 +0100
                      Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 16:13 +0100
                        Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 17:45 +0100
                          Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 18:44 +0100
                            Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:19 +0100
                          Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 14:43 -0800
                            Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:30 +0100
                              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 21:51 -0800
                                Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 01:43 +0100
                                  Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:55 +0000
                                    Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 21:01 +0100
                              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-25 23:22 -0800
                                Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-26 15:11 +0100
                                  Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 08:05 -0500
                                    Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 22:14 -0500
                                      Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 22:56 -0500
                                        Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:37 -0500
                                          Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-07 13:12 -0500
                                      Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-28 08:00 -0800
                                        Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
                                      Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-02-28 16:55 +0000
                                        Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
                                          Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:08 +0000
                                            Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 03:39 -0800
                                              Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:49 -0500
                                                Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:20 +0000
                                                Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:12 -0800
                                                  Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-08 04:21 -0500
                                            Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:50 -0500
                                              Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 07:16 +0000
                                                Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:56 -0500
                                                  Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:24 -0800
                                                    Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 07:34 -0800
                                  Re: Integer cosine function Lars Brinkhoff <lars.spam@nocrew.org> - 2013-02-28 12:57 +0100
                                    Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:07 +0100
                                  Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-28 19:37 -0800
                                    Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-01 10:56 +0000
                                      Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-01 13:52 +0000
                                        Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:48 -0800
                                      Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-13 17:44 -0400
                                    Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:36 -0500
                                      Re: Integer cosine function Elizabeth D Rather <erather@forth.com> - 2013-03-01 19:14 -1000
                                        Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-03-02 09:34 +0200
                                      Re: Integer cosine function kenney@cix.compulink.co.uk - 2013-03-02 09:06 -0600
                                Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-26 08:53 -0800
                                Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-26 16:59 -0500
                                  Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-27 00:52 +0000
                                    Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:07 -0500
                                Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 20:51 +0000
                              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:58 -0800
                                Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 16:39 +0100
                                  Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 14:21 -0800
                                    Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 00:11 +0100
                                      Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 23:44 +0000
                                      Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 16:24 -0800
                                        Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 01:59 +0100
                                          Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 19:48 -0800
                                            Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 16:22 +0100
                                    Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-06 23:37 +0000
                            Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 09:54 -0500
                            Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 21:03 +0000
                              Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 15:59 -0800
                                Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 16:38 -0800
                      Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:07 -0600
                        Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:39 +0100
                          Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:23 -1000
                          Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:44 -0600
                      Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 13:00 -0800
                        Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:09 +0100
                      Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 21:16 -0500
                    Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 20:28 -0500
    Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 07:59 -0800
      Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-27 08:48 -0800
        Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 10:23 -0800
        Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 10:14 -0700
          Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:19 -0700
            Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:28 -0700
              Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 21:13 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#19899

rickman wrote:

> On 2/21/2013 7:04 AM, Bernd Paysan wrote:
>>
>> Most decisions people make are irational personal taste decisions. 
>> Blaise
>> Pascal already noticed that a few centuries ago.  It's just that way.  My
>> personal taste is that the 8051 is utter crap.  Though there are worse
>> things than the 8051 ;-).
> 
> I had not heard that about Pascal.

Blaise Pascal argued against Descartes' rationalism, and to him, humans are

a) not actually that rational and
b) rational reasoning isn't always helpful

The entire stuff is of course 17th century philosophy, and Pascal is an 
important contributor.

> It seems to be true though and
> contrary to one of the basic premises of Keynesian economic theory that
> everyone bases their decisions on "perfect knowledge" so as to maximize
> their utility.  Obviously they may be what they think they are doing,
> but they seldom have "perfect knowledge" and often don't really make
> good decisions.

Current economists try to model imperfect knowledge, and there are even 
proofs that the "perfect knowledge" is np-complete.  However, this all does 
not tell you how good the heuristics are.  The herd mentality is a 
heuristics.

> Even corporations can be run by the "herd" mentality.  Look how many
> times all the companies in a given area start doing the same things even
> when they turn out poorly.  Did they all just happen to make the same
> bad decision?  Or were they all following each other as in a herd?

It is hard to tell.  Sometimes, uninformed decisions tend to go into a 
particular direction, because they are made by people, and people are alike.  
Sometimes, the decision is "informed" by advertizing, and the one with the 
biggest marketing budget won.  And sometimes, it's based on managers 
chatting in the golf club, which means they follow the herd.

Often, you see cultural clashes.  Management decides that Apple is cool, and 
the company should now use Apple computers and iPads and so on (of course 
influenced by Apple's marketing).  The IT is horrified, because they have 
done Windows for 20 years, and don't know anything about Apple, which they 
heard is some Unix, so management asks the bearded server&workstation guys.  
They say "Well, Apple is somewhat a bit like Linux, but it's proprietary 
crap and insecure and you shouldn't buy this.  BTW: you shouldn't have 
bought this Windows crap, either, and here's a free offer to install Debian 
on your laptop, and make the next presentation with LaTeX Beamer using vi or 
emacs, please."  Management is pissed, because their authority is 
questioned.

The result is: Anybody who is of higher rank than the head of IT will get a 
shiny MacBook retina, on which IT installs Windows XP in a virtual machine, 
so that the bosses can use IE6 to look into the status reports on the 
intranet, everybody else will get a Windows XP Dell box, and the 
server&workstation users will get RHEL4.  Because RHEL5 and 6 are too new to 
be trustworthy, and well, doesn't feel like Solaris.

Is any of these decisions based on rational reasoning?  Is the status report 
tool that depends on IE6 really a good idea?  I've read a study about how 
punishment bends people: Their ethics moves from right and wrong to honor 
and loyalty, and that especially the police and military tend to go that 
way.  This reminds me of the SS' motto "Meine Ehre heißt Treue" ("my honor 
is called loyalty"), a military police force, the worst you can imagine - it 
really works that way.

I've worked for slightly more than a year for a company that did use 
punishment, and they tried it on me in the end.  I decided that I don't like 
BDSM, and did quit instantly - you don't punish me, you don't even get a 
second chance for trying, if you want that I work for you, you have to keep 
me happy.  But I do understand why the people who were there for longer were 
all frightened, didn't question decisions, and made defensive and 
conservative decisions themselves, when they were in charge.  These 
decisions aren't rational, they are driven by fear.  And I don't think gut 
feelings are wrong - when I did the first interview with that company a few 
years before they bought me with team, my gut feeling was "these people are 
to be avoided".  The feeling was correct.  Did I rationalize my gut feelings 
in the end, when I had collected enough data, as Pascal would put it?

> Once I read that insurance companies don't like to stand out from the
> crowd because that is unnecessary exposure to risk.  If they all share
> in a major loss, none are more likely than the others to be devastated
> by it.  So insurance companies don't want to dominate in any geographic
> or business areas.

Insurance companies should make their decisions from risk analysis, which 
bogs down to statistics (if done right).  If an insurance company has 
significantly better conditions for e.g. car accidents than their 
competition, and they then win the majority of the contracts, it is very 
likely because they underestimated the risks.  Some insurances are dominated 
by administrative costs, and there, you can easily become market leader by 
driving those down (that are those which maybe cost 30€/year).

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

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

#19905

On Feb 22, 1:45 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Often, you see cultural clashes.  Management decides that Apple is cool, and
> the company should now use Apple computers and iPads and so on (of course
> influenced by Apple's marketing).  The IT is horrified, because they have
> done Windows for 20 years, and don't know anything about Apple, which they
> heard is some Unix, so management asks the bearded server&workstation guys.
> They say "Well, Apple is somewhat a bit like Linux, but it's proprietary
> crap and insecure and you shouldn't buy this.  BTW: you shouldn't have
> bought this Windows crap, either, and here's a free offer to install Debian
> on your laptop, and make the next presentation with LaTeX Beamer using vi or
> emacs, please."  Management is pissed, because their authority is
> questioned.
>
> The result is: Anybody who is of higher rank than the head of IT will get a
> shiny MacBook retina, on which IT installs Windows XP in a virtual machine,
> so that the bosses can use IE6 to look into the status reports on the
> intranet, everybody else will get a Windows XP Dell box, and the
> server&workstation users will get RHEL4.  Because RHEL5 and 6 are too new to
> be trustworthy, and well, doesn't feel like Solaris.
>
Hey! You didn't tell me you have come to work at my place! Which
building are you in? I'll buy you lunch! :-)

> I've worked for slightly more than a year for a company that did use
> punishment, and they tried it on me in the end.  I decided that I don't like
> BDSM, and did quit instantly - you don't punish me, you don't even get a
> second chance for trying, if you want that I work for you, you have to keep
> me happy.  But I do understand why the people who were there for longer were
> all frightened, didn't question decisions, and made defensive and
> conservative decisions themselves, when they were in charge.  These
> decisions aren't rational, they are driven by fear.  And I don't think gut
> feelings are wrong - when I did the first interview with that company a few
> years before they bought me with team, my gut feeling was "these people are
> to be avoided".  The feeling was correct.  Did I rationalize my gut feelings
> in the end, when I had collected enough data, as Pascal would put it?
>

I'm intriuged by this. Why did you go against your gut instinct?

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

#19908

Mark Wills wrote:
>> I've worked for slightly more than a year for a company that did use
>> punishment, and they tried it on me in the end.  I decided that I don't
>> like BDSM, and did quit instantly - you don't punish me, you don't even
>> get a second chance for trying, if you want that I work for you, you have
>> to keep me happy.  But I do understand why the people who were there for
>> longer were all frightened, didn't question decisions, and made defensive
>> and conservative decisions themselves, when they were in charge.  These
>> decisions aren't rational, they are driven by fear.  And I don't think
>> gut feelings are wrong - when I did the first interview with that company
>> a few years before they bought me with team, my gut feeling was "these
>> people are to be avoided".  The feeling was correct.  Did I rationalize
>> my gut feelings in the end, when I had collected enough data, as Pascal
>> would put it?
>>
> 
> I'm intriuged by this. Why did you go against your gut instinct?

They simply bought us on the slave market, it was decided over my head.  No, 
this wasn't in Mississippi, where they had formally abolished slavery just 
now.

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

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

#19933

On Feb 21, 6:45 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Blaise Pascal argued against Descartes' rationalism, and to him, humans are
>
> a) not actually that rational and
> b) rational reasoning isn't always helpful
>
> The entire stuff is of course 17th century philosophy, and Pascal is an
> important contributor.
>
> > It seems to be true though and
> > contrary to one of the basic premises of Keynesian economic theory that
> > everyone bases their decisions on "perfect knowledge" so as to maximize
> > their utility.  Obviously they may be what they think they are doing,
> > but they seldom have "perfect knowledge" and often don't really make
> > good decisions.
>
> Current economists try to model imperfect knowledge, and there are even
> proofs that the "perfect knowledge" is np-complete.  However, this all does
> not tell you how good the heuristics are.  The herd mentality is a
> heuristics.

One of my all-time favorite books is: "The Scapeweed Goat" (Frank
Schaefer).

At one point, the main character mentioned how the White people killed
off all buffalo. If the concept of reincarnation is true, then we have
to wonder: where did the buffalo go? They can't be reincarnated as
buffalo, because there are only a tiny population of buffalo compared
to the vast numbers that had previously lived. His theory is that the
buffalo must have been reincarnated as humans --- pointing out that
there are now a vast number of people compared to the tiny population
of the past, which implies that the people couldn't have been
reincarnated from previous generations of people.

This theory actually explains quite a lot! If the people seem to have
a herd mentality, it is because they were buffalo in their last life.
This also explains so many people's utter failure to grasp technology
--- these computer thingies are a pretty big jump from grazing on
grass in the plains. Makes sense to me!

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

#19947

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:97150c0f-011e-4e80-a7d3-c2b361cca437@y4g2000yqa.googlegroups.com...

> One of my all-time favorite books is: "The Scapeweed Goat"
> (Frank Schaefer).
>
> At one point, the main character mentioned how the White
> people killed off all buffalo. If the concept of reincarnation
> is true, then we have to wonder: where did the buffalo go?
> They can't be reincarnated as buffalo, because there are only
> a tiny population of buffalo compared to the vast numbers
> that had previously lived. His theory is that the buffalo must
> have been reincarnated as humans --- pointing out that there
> are now a vast number of people compared to the tiny
> population of the past, which implies that the people couldn't
> have been reincarnated from previous generations of people.

Non sequiter.

Assuming the premise is true, the buffalo could've been
reincarnated as ants, mosquitoes, plankton, angels, aliens who
live far, far away, or even alien buffalo's...  What you dispute
being reincarnated as angels?  Well, no one woul ever notice the
reincarnation if it was as ants or plankton...

He used a decline of a population as his "proof".  What about the
increase of a population?  If reincarnation is real, then how did
we get from 100,000 human beings to 5 billion?  "What" exactly
died so that we could be reincarnated as humans? ...

I.e., the original premise, reincarnation is real, is in all
likelyhood, invalid.

> This theory actually explains quite a lot! If the people seem
> to have a herd mentality, it is because they were buffalo in
> their last life.  This also explains so many people's utter
> failure to grasp technology --- these computer thingies are
> a pretty big jump from grazing on grass in the plains.
> Makes sense to me!

And, I can prove that humans had furry tails.  Yes, not just
tails, but *furry* tails.  Remnant psychology, that stuff in your
brain that just doesn't get filtered out by evolution or excised
by God and was used to great effect by Sigmund Freud, strongly
indicates we had furry tails.  Mice, rats, possums, armidillos,
snakes, and alligators, etc., have tails but no fur.  We hate
them.  Cats, dogs, chicks, bunnies, foxes, squirrels, rabbits,
ferrets, and hamsters, etc., all have furry tails.  We love them.
They're so cute!  With every breath we take, we just want to
shower them with endless love.  You can't resist their charms.
Therefore, humans had furry tails in the past.  Why else would we
express such love for furry tails?  We used them to recognize each
other.  Makes sense to me!  See, I just proved it.  And, I
perfectly validated the Theory of Evolution at the same time by
using modern psychology, while using neuro-linquistic programming
to have you think of "Endless Love" by Lionel Ritchie...  Top
that!

If you reference this in the future, please refer to it as:
"RPFTP - Rod Pemberton's Fury Tail Proof".
Thank you.


Rod Pemberton

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

#19903

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Gary Bergstrom wrote:
>> In the embedded world you should look at how many new chips have an
>> embedded 8051 in them for control. It's hard to spin your own chips
>> using a "informed decision". Easier to buy what is cheap and
>> available. Maybe the vendors will start to switch to some better
>> choice, but I see more and more embedded 8051's every month.
> 
> Most decisions people make are irational personal taste decisions.
> Blaise Pascal already noticed that a few centuries ago.  It's just
> that way.  My personal taste is that the 8051 is utter crap.  Though
> there are worse things than the 8051 ;-).

You need to point that arrow of reasoning back at yourself, though:
you don't like the 8051, so you consider people who choose it to be
irrational!  The truth is that all of us make decisions for emotional
reasons and save our intellectual firepower to construct elaborate
rationalizations to justify them.

Andrew.

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

#19904

On Feb 22, 9:59 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
>
> You need to point that arrow of reasoning back at yourself, though:
> you don't like the 8051, so you consider people who choose it to be
> irrational!  The truth is that all of us make decisions for emotional
> reasons and save our intellectual firepower to construct elaborate
> rationalizations to justify them.
>
> Andrew.

Very wise words.

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

#19907

Andrew Haley wrote:
> You need to point that arrow of reasoning back at yourself, though:
> you don't like the 8051, so you consider people who choose it to be
> irrational!

I've had no exposure to the 8051 before that project, I was completely 
agnostic at that point of time.  I started to hate it when I saw what kind 
of crap it was.  The b16 came into existence as I was motivated to do 
something better, and it took me only *days* to do so.  I struggled about 
half a year with the various IPs from Inventra (8051, debugger, USB, and 
writing test code in 8051 assembler), only to glue them together.

I've ported Gforth to a competitor of the 8051, the R8C, it took a week to 
get Gforth up and running.  It is a nice CPU.  I also like the msp430.  
There are nice CPUs in the 8051 ballpark out there, and there is crapware 
like the 8051, and it *does* impact my productivity.  After I'm slowed down 
for enough time, I start to get emotional.

> The truth is that all of us make decisions for emotional
> reasons and save our intellectual firepower to construct elaborate
> rationalizations to justify them.

Yes, after struggling half a year with utter crap, I have emotional reasons.  
It wouldn't have taken half a year it it wasn't crap.  Part of the crappy 
feeling of course was the Inventra implementation, which looked like some 
beginner from India wrote it (it couldn't talk to synchronos SRAM, and all 
the SRAM blocks you can compile are synchronous, because synchronous is the 
right way to do it), the other part of the "this is crap" feeling came from 
writing test code in assembler.  This CPU is certainly not the best of 
breed.  And I have seen many CPUs.

And then I talked to the consultant who wrote a significant part of the 
firmware.  She complained about the crappy Keil compiler, the half-working 
debugger, and that there are better CPUs out there...  And of course, we 
were accused of producing crap, too.  Because the debugger had some flaws, 
which we did somehow overcome at our side, but the people who used it 
together with the Keil didn't, and finally, they got some support from the 
subcontractors who made the debugger for Inventra (it was all outsourced, 
Inventra did nothing themselves)...  because the Keil interface to that 
debugger really didn't work.

Well, the decision makers have never seen any other CPU.  Their boss at the 
beginning thought about using ARM, but ARM was too big and therefore too 
expensive.  Their boss didn't like the 8051 at all, but they also blocked 
his decision to go 0.35µ instead of 0.5µ, because his disciples thought, it 
would be too difficult to generate the 3.3V on-chip (which we had to 
generate anyways, because it was an USB device - and USB logic level is 
3.3V.  Doh!).

In so far, I completely trust my gut feelings.  This isn't stupidity when we 
get emotional.  For fun, we later always included the 8051 in our decision 
sheets, with performance and size of the Inventra implementation, and it 
never was a viable competitor.

Have I mentioned that the complete team we worked together with has been 
sacked when the chip finally went into mass production?  The new people 
caring for the product were at first reluctand to talk to us, but they soon 
figured out that it wasn't us who were the jerks ;-).  It was just a 
slightly violation of the USB signal spec, and when they approached us, my 
response was "yes, we know this, yes, we can fix this, and yes, we already 
talked about this, and your predecessors didn't want us to fix it."

With a more 21st century approach, I would say that emotions is what gives 
us drive.  It is our brain which decides, and we need emotions to get these 
decisions through, so our brain generates these emotions.  And yes, we make 
"rational" arguments, because following Descartes, we are supposed to be 
rational beings.  But when those arguments turn out to be factually wrong, 
we usually don't redecide.  We stick to our emotions, because they provide 
more drive than a rational argument.  The question wether we came to this 
conclusion through an evidence-based approach or through other approaches 
doesn't matter.  It is probably provable that any thinking thing can't be 
understood from the inside.

http://xkcd.com/1163/

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

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

#19909

In comp.lang.forth, Bernd Paysan wrote:

> I've had no exposure to the 8051 before that project, I was completely 
> agnostic at that point of time.  I started to hate it when I saw what kind 
> of crap it was.  The b16 came into existence as I was motivated to do 
> something better, and it took me only *days* to do so.  I struggled about 
> half a year with the various IPs from Inventra (8051, debugger, USB, and 
> writing test code in 8051 assembler), only to glue them together.
>
> I've ported Gforth to a competitor of the 8051, the R8C, it took a week to 
> get Gforth up and running.  It is a nice CPU.  I also like the msp430.  
> There are nice CPUs in the 8051 ballpark out there, and there is crapware 
> like the 8051, and it *does* impact my productivity.

But, actually, what makes it so crappy? What's wrong with 8051? It's very
ubiquitous. Is it possible, that having better offers, so many people choose
"crap" instead?
-- 
It's us, the scobs.

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

#19912

Zbiggy wrote:

> In comp.lang.forth, Bernd Paysan wrote:
>> I've ported Gforth to a competitor of the 8051, the R8C, it took a week
>> to
>> get Gforth up and running.  It is a nice CPU.  I also like the msp430.
>> There are nice CPUs in the 8051 ballpark out there, and there is crapware
>> like the 8051, and it *does* impact my productivity.
> 
> But, actually, what makes it so crappy? What's wrong with 8051? It's very
> ubiquitous. Is it possible, that having better offers, so many people
> choose "crap" instead?

Yes.  Because these people usually don't know of the better offers.  The say 
"the 8051 is ubiquitous, and million flies can't be wrong."  Wikipedia has a 
nice article why "ad populum" is a fallacy:

http://en.wikipedia.org/wiki/Argumentum_ad_populum

Informed decisions are not easy.  You have to look at different CPUs, and 
carefully evaluate their capabilities, write code on them, look at how they 
perform, and when you use them inside a SoC, look at the implementation and 
judge how good that is.  So what did my customers say when I asked them why 
they want to use the 8051?  "We have used the 8051 20 years ago" (which 
meant right after the 8051 was released, because they came to us in 2001).  
Ok, I really believe they did, because they looked old enough.  In 1980, the 
8051 was a hot new microcontroller, and one of the first single-chip 
microcontrollers.

They also explained to me that we need to use a steep bandpass filter for 
the acoustic surface wave, because they have used a colorburst filter for 
that 20 years ago.  Yes, if you build such a touch screen out of discrete 
components as a prototype, using a NTSC colorburst filter from a color TV is 
a clever idea.  If you do that all in full custom silicon, using a 
synchronous demodulator is the way to go.  But that would be new, and not 
tested.

The 8051 design was originally meant as single-chip controller with an on-
chip 4k instruction ROM, and a small, byte-addressed RAM, including special 
function registers in that address space (the RAM is 128 bytes, leaving 
space for another 128 bytes of special function registers).  The killer 
feature of the 8051 were the bit operations for selected IOs and RAM 
registers (BTW: The first deployment of the b16 had some modifications, and 
one of them was bit manipulation).

If you use such a controller, you don't need many features, it is pretty 
small, and you want the program to be compact.  The original 8051 used a 12 
cycle microcode engine, which meant it also was pretty slow, and the 
instruction set as a result was designed in a way that makes fast 
implementations pretty hard to do.

As this is really not big enough for most uses of the 8051 today, people 
added an "external RAM" address space (which really is internal, as well), 
and increased the code memory, which today is flash, not mask-programmed 
ROM.  This IMHO completely ruins the architecture, because that wasn't the 
original design goal.  All these controllers have pretty narrow design 
goals, and that's actually a good thing - as we Forthers know, you should 
not imagine the future, but build for the problem at hand.  In so far, as 4k 
code+128 bytes RAM machine, the 8051 is, considered state-of-the-art of now 
30 years ago, *not* horrible, or, let's say, not that much more horrible 
than the competition like the PIC16.  But it's not designed for anything 
bigger than that.  The PICs at least got a new instruction set for each 
generation, each of them better than the one before, though each of them, 
from today's knowledge, certainly byzantine.

I think one of the reasons why the 8051 is so popular for SoCs is that Intel 
soon lost interest in selling them, while clones were already on the market 
(and Intel had licensed the 8051 from the beginning, which created an 
industry standard).  This means the architecture is completely free and open 
to clone for whoever likes to, and has been for a long time.  Openness is an 
advantage by itself, even if there are no technical merits behind.  Compare 
ARM: You *have* to buy this from ARM, and pay an arm and a leg for it.  No 
second source for their IP.  Thanks to openCore, you now can also have other 
popular controllers as open softcore IP, like the MSP430.  But for a long 
time, that wasn't the case.  And many developer don't feel like creating a 
CPU *and* the necessary toolchain (which I needed to do for the b16, being 
Forth, it was a piece of cake), usually they rather like to take things from 
the shelf and plug them in.

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

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

#19917

In comp.lang.forth, Bernd Paysan wrote:

> If you use such a controller, you don't need many features, it is pretty 
> small, and you want the program to be compact.  The original 8051 used a 12 
> cycle microcode engine, which meant it also was pretty slow, and the 
> instruction set as a result was designed in a way that makes fast 
> implementations pretty hard to do.

But, actually, this is the main disadvantage you're writting about. And this
makes 8051 a crap? Even in a Wikipedia found an explaining:

#v+
The original Intel 8051 ran at 12 clock cycles per machine cycle, and most
instructions executed in one or two machine cycles. A typical maximum clock
frequency of 12 MHz meant these old 8051s could execute one million
single-cycle instructions, or 500,000 two-cycle instructions, per second.
In contrast, enhanced 8051 silicon IP cores now run at one clock cycle per
machine cycle, and have clock frequencies of up to 450 MHz. That means an
8051-compatible processor can now execute 450 million instructions per
second.
#v-

An example could be DS89C430 (450) - pin and instruction compatible with 8051.

> As this is really not big enough for most uses of the 8051 today, people 
> added an "external RAM" address space (which really is internal, as well), 
> and increased the code memory, which today is flash, not mask-programmed 
> ROM.  This IMHO completely ruins the architecture, because that wasn't the 
> original design goal.

Do you mean: complicated memory organization?
-- 
It's us, the scobs.

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

#19921

Zbiggy wrote:

> In comp.lang.forth, Bernd Paysan wrote:
> 
>> If you use such a controller, you don't need many features, it is pretty
>> small, and you want the program to be compact.  The original 8051 used a
>> 12 cycle microcode engine, which meant it also was pretty slow, and the
>> instruction set as a result was designed in a way that makes fast
>> implementations pretty hard to do.
> 
> But, actually, this is the main disadvantage you're writting about.

And the unnecessarily complicated memory?

> And this makes 8051 a crap? Even in a Wikipedia found an explaining:
> 
> #v+
> The original Intel 8051 ran at 12 clock cycles per machine cycle, and most
> instructions executed in one or two machine cycles. A typical maximum
> clock frequency of 12 MHz meant these old 8051s could execute one million
> single-cycle instructions, or 500,000 two-cycle instructions, per second.
> In contrast, enhanced 8051 silicon IP cores now run at one clock cycle per
> machine cycle, and have clock frequencies of up to 450 MHz. That means an
> 8051-compatible processor can now execute 450 million instructions per
> second.
> #v-

Yes, with technology where an ARM runs at 2GHz or an x86 runs at 4GHz.  Note 
that still you have many 2-cycle instructions on these high-speed 8051, too 
(the old "single-cycle" instructions, which took 12 cycles back then are now 
single-cycle instructions which take one cycle).  The size of such an 8051 
on silicon is considerably bigger than a Cortex M0, because it is so hard to 
make it fast.

> An example could be DS89C430 (450) - pin and instruction compatible with
> 8051.
> 
>> As this is really not big enough for most uses of the 8051 today, people
>> added an "external RAM" address space (which really is internal, as
>> well), and increased the code memory, which today is flash, not
>> mask-programmed
>> ROM.  This IMHO completely ruins the architecture, because that wasn't
>> the original design goal.
> 
> Do you mean: complicated memory organization?

Yes, complicated memory, difficult to manage especially in a HLL.  If you 
look at the 6805 or similar other CPUs of that age, you see that a uniform 
address space is no problem at all - you even can have your zero-page with 
byte addresses, without fragmenting the address space.

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

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

#19929

On Feb 22, 9:45 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Zbiggy wrote:
> > In comp.lang.forth, Bernd Paysan wrote:
> >> I've ported Gforth to a competitor of the 8051, the R8C, it took a week
> >> to
> >> get Gforth up and running.  It is a nice CPU.  I also like the msp430.
> >> There are nice CPUs in the 8051 ballpark out there, and there is crapware
> >> like the 8051, and it *does* impact my productivity.

This is utter nonsense! You don't port GForth to anything --- you
(actually, somebody smart) ports GCC to new processors --- then, all
of the GCC programs (including GForth) get dragged along with it. The
whole point of writing GForth in C rather than assembly-language was
to dump the work of porting to new processors onto the GCC guys, and
lift this heavy burden from the bony-unmuscled shoulders of the GForth
community.

It seems wrong that you should call the 8051 or anything else "crap"
--- GForth is truly crap, as it runs about an order of magnitude too
slow for any serious application --- all this talk about "crap"
reminds me a lot of how my own software is said to "suck" here in
C.L.F.. Don't you guys have anything better to do with your time than
to fling vulgar epitaphs at everybody in the world who writes software
or builds a chip? --- you know, like spend some time writing a Forth
compiler that would actually be useful?

> The 8051 design was originally meant as single-chip controller with an on-
> chip 4k instruction ROM, and a small, byte-addressed RAM, including special
> function registers in that address space (the RAM is 128 bytes, leaving
> space for another 128 bytes of special function registers).  The killer
> feature of the 8051 were the bit operations for selected IOs and RAM
> registers (BTW: The first deployment of the b16 had some modifications, and
> one of them was bit manipulation).

The bit-logic instructions made the 8051 a good choice for PLCs ---
that was the "killer app" that made the chip. I would estimate that
there are at least an order of magnitude more PLCs in use than micro-
controllers.

Also, memory was extremely tight in the old days. The 8051 had a very
clever memory system that allowed significantly more that 256 cells to
be addressed, while still using only 8-bit registers. The 8-bit
Motorola processors, such as the 6805 etc., required 16-bit pointers
for most of the memory, which results in code that is both slow and
bloated.

Also, most micro-controller applications are heavily interrupt driven
--- it is common for over 50% of the time to be spent in ISRs. The
8051 had a very clever system in which there were 4 register banks ---
each ISR could have its own register set without a lot of time spent
saving and restoring registers on the stack.

All in all, the 8051 was a very good design for its day. The only bad
thing about the 8051 was that it didn't support high-level languages
very well, but that really wasn't what it was designed for. Within the
context that it was designed, it was the best --- it still is, as the
world hasn't gotten much more complicated since the 1980s, and many
applications are no bigger or more complicated now than they were
then.

> As this is really not big enough for most uses of the 8051 today, people
> added an "external RAM" address space (which really is internal, as well),
> and increased the code memory, which today is flash, not mask-programmed
> ROM.

On that subject, why are we even discussing the 8051? The 8051 is only
used in mass-produced items. For low volume productions, which is the
only kind of thing that somebody such as myself would be involved in,
the 8032 would be used.

Actually by the early 1990s, the Dallas 80c320 had largely taken over.
It provided 2K of RAM on chip, and it had two 16-bit pointers. The
8051/8032 had only one 16-bit pointer, which made it incredibly
awkward for even simple functions such as moving a chunk of memory
from one place to another.

Testra used the 80c320 for everything. The 80c320 was used in the
motion-control board but it was struggling, which is why the MiniForth
was introduced. That was a pretty demanding application though --- the
80c320 was used for most everything else with success.

> In so far, as 4k
> code+128 bytes RAM machine, the 8051 is, considered state-of-the-art of now
> 30 years ago, *not* horrible, or, let's say, not that much more horrible
> than the competition like the PIC16.  But it's not designed for anything
> bigger than that.  The PICs at least got a new instruction set for each
> generation, each of them better than the one before, though each of them,
> from today's knowledge, certainly byzantine.

The PIC chips were tough to program due to the lack of registers and
the bank-switched memory up through the PIC18 (I programmed the PIC16,
but they are all pretty much the same).

The PIC24 was a huge step forward however. It has 16 16-bit registers,
plus 4 more that can be switched in and out for fast ISRs. With 8K or
16K of RAM built-in, and with 16-bit registers, it is no longer
necessary to use the banked-memory systems of the older chips, but
linear addressing can be used instead. All in all, the PIC24 is an
awesome processor.

> I think one of the reasons why the 8051 is so popular for SoCs is that Intel
> soon lost interest in selling them, while clones were already on the market
> (and Intel had licensed the 8051 from the beginning, which created an
> industry standard).  This means the architecture is completely free and open
> to clone for whoever likes to, and has been for a long time.  Openness is an
> advantage by itself, even if there are no technical merits behind.

Intel made an effort to make their processor industry-standard, and
they succeeded wonderfully. For one thing, they just stuck with it
forever, rather than change the design every few years. They added
features, such as more memory and faster speed, without losing
compatibility.

By comparison, Motorola would come out with a new-and-improved
processor every few years, and they alienated their customers. Nobody
wants to learn a new assembly-language and rewrite all of their code
periodically, without any significant step up in capability (besides
that, if the old stuff was working, then the customer wasn't demanding
any new capability anyway).

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

#19931

Hugh Aguilar wrote:

> On Feb 22, 9:45 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> Zbiggy wrote:
>> > In comp.lang.forth, Bernd Paysan wrote:
>> >> I've ported Gforth to a competitor of the 8051, the R8C, it took a
>> >> week to
>> >> get Gforth up and running.  It is a nice CPU.  I also like the msp430.
>> >> There are nice CPUs in the 8051 ballpark out there, and there is
>> >> crapware like the 8051, and it *does* impact my productivity.
> 
> This is utter nonsense! You don't port GForth to anything

I'm talking about Gforth EC, which is a "traditional" all Forth+assembler 
controller Forth.  It reuses the Forth part of Gforth (slimmed down a bit), 
and does the stuff that are primitives in C in a mixture of assembler (real 
primitive) and Forth (replacement code).  The problem with you is that you 
have some emotional reasons against Gforth, and therefore you ignore all 
facts about it.

> --- you
> (actually, somebody smart) ports GCC to new processors --- then, all
> of the GCC programs (including GForth) get dragged along with it. The
> whole point of writing GForth in C rather than assembly-language was
> to dump the work of porting to new processors onto the GCC guys, and
> lift this heavy burden from the bony-unmuscled shoulders of the GForth
> community.

Haha.  That's where GCC does have a backend.  For processors where it 
doesn't it goes back to the strong shoulders of the Gforth community.

Well, maybe the C backend was the wrong choice in the long run.  In the 
short run, 20 years ago, with its many RISC processors, it seemed to be a 
good choice.  The RISC processors died one after the other, and nowadays, 
it's x64 and ARM, and a little MIPS.

> It seems wrong that you should call the 8051 or anything else "crap"
> --- GForth is truly crap, as it runs about an order of magnitude too
> slow for any serious application

Come back with your toyforth when it is 10 times faster than gforth-fast, 
then we can discuss about that.  Neither VFX nor iForth are a factor 10 
faster than gforth-fast.  Whatever you did when you measured Gforth, you had 
bad karma.

> All in all, the 8051 was a very good design for its day. The only bad
> thing about the 8051 was that it didn't support high-level languages
> very well, but that really wasn't what it was designed for.

Fully agreed.  But when your customer wants to deliberately use a HLL for 
his application, then chosing the 8051 is stupid.  And it wasn't a PLC-like 
controller, it was something that had to do calculations most of the time.

> Within the
> context that it was designed, it was the best --- it still is, as the
> world hasn't gotten much more complicated since the 1980s, and many
> applications are no bigger or more complicated now than they were
> then.

Fine.  But that context is PLC-like control, as you figured out.  It's not 
crap for that context, but that wasn't the context I (and our customer) used 
embedded controllers in.

> Intel made an effort to make their processor industry-standard, and
> they succeeded wonderfully. For one thing, they just stuck with it
> forever, rather than change the design every few years. They added
> features, such as more memory and faster speed, without losing
> compatibility.
> 
> By comparison, Motorola would come out with a new-and-improved
> processor every few years, and they alienated their customers. Nobody
> wants to learn a new assembly-language and rewrite all of their code
> periodically, without any significant step up in capability (besides
> that, if the old stuff was working, then the customer wasn't demanding
> any new capability anyway).

Yes, Intel really is good at maintaining compatibility.  You still can run 
your 8080 code through a special assembler, and run it on an x86.  Core i7, 
if you like, and it will work.  Out of the box.  Our customer had the same 
argument, i.e. software reuse.  It was software written in C, and it was 
completely rewritten from scratch for that project.  What?  No 8051 
assembler legacy?  Yes.  So why choose an 8051?

For that customer, the b16 wouldn't have been the right choice, either, 
because there's no C compiler for it.  The b16 is only right when you 
program it in Forth.  The ARM suggested from upper management would have 
been a better choice.

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

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

#19932

On Feb 22, 5:30 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > All in all, the 8051 was a very good design for its day. The only bad
> > thing about the 8051 was that it didn't support high-level languages
> > very well, but that really wasn't what it was designed for.
>
> Fully agreed.  But when your customer wants to deliberately use a HLL for
> his application, then chosing the 8051 is stupid.  And it wasn't a PLC-like
> controller, it was something that had to do calculations most of the time.

Well, arithmetic was the reason why the 80c320 was dropped for the
motion-control program. The #1 goal with the MiniForth was a 16x16
multiplication in 1 uSec.. Actually, I pointed out at the time that
the 6812 did that already, but Testra was all about Forth so they took
the extravagant step of building their own processor based on a PLD.

I agree that the 8051 (and the more advanced 80c320 as well) are a bad
choice for HLLs (both C and Forth). I'm just sick and tired of all
this troll behavior --- saying that things are "crap" and they "suck"
and so forth. I remember a time when Forth was taken seriously. Forth
failed badly though and it is completely forgotten now --- the Forth
community has descended into a nest of vipers that strike out at
everybody that comes near, and are avoided by everybody.

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

#19974

Hugh Aguilar wrote:
> I agree that the 8051 (and the more advanced 80c320 as well) are a bad
> choice for HLLs (both C and Forth). I'm just sick and tired of all
> this troll behavior --- saying that things are "crap" and they "suck"
> and so forth.

"sick and tired" is also a word of this category, though probably weaker 
than "crap".  As we have been talking about emotions, these words are tied 
to strong emotions, and the meaning they convey is to transfer the strong 
emotion the speaker has to the reader's brain.  I have strong negative 
emotions to the quality of the 8051 as microcontroller to be used for the 
application domain I worked in, and the terse way to communicate this is 
"crap".

It is a cultural thing.  This is Usenet, and it has been that way since it 
started.

> I remember a time when Forth was taken seriously. Forth
> failed badly though and it is completely forgotten now --- the Forth
> community has descended into a nest of vipers that strike out at
> everybody that comes near, and are avoided by everybody.

I remember a lot of statements from yourself which are pretty well described 
by this - and for that reason I had killfiled you for some time.  I clean up 
my killfile from time to time, this is not a death penalty.  In any case, 
what we hear is often just the echo of what we say.  We say, your code 
sucks, you say, our code sucks, and we shouldn't dig down the archive who 
started, because perpetual wars are fueled by both sides.

My memory of the "good times" of Forth is a bit different.  There was a time 
where computer hobbyists wanted to program 8 bit processors, which were too 
small for any of those languages taught in academic courses.  Even for 
Pascal, which was pretty lightweight.  At that time, people used BASIC (big 
majority) and Forth (smart minority), and both were highly controversial - 
BASIC was "crap", and Forth was something "nobody understood".  The end of 
Forth as somewhat popular language IMHO came with TurboPascal, which brought 
a language accepted by academics onto mainstream home computers, and its 
implementation quality was excellent for a very reasonable price.  At that 
time, the Forth landscape was fragmented into many mediocre systems, which 
led to the golden words that "when you have seen one Forth, you have seen... 
one Forth."

The fact that it is *much harder* to get a Pascal compiler and IDE working 
in just 64k meant that Anders Hejlsberg simply was the only game in town.  
Academics means that this was taught at universities, and it was the first 
academic language that got a pretty useable implementation on home 
computers.  That's what IMHO killed Forth as popular language on a home 
computer, together with the varying quality of the many Forth compilers 
available.

Computer science as academics is a side branch of mathematics, and it shows.  
If you look at languages which are popular in academics, and almost unused 
anywhere else, you find things like Haskell, which is really close to the 
math computer scientists use to think about computers.  Forth is the other 
way round: It is to make the human think the way the computer actually 
works, in a minimalistic way (actual computers are more complicated than 
Forth machines, but that can be dismissed as accidential complication - it's 
not inherent to the computer as such, and you don't lose anything when 
removing these parts).

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

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

#20022

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Computer science as academics is a side branch of mathematics, and it shows.  

Theoretical computer science is a branch of mathematics.  The other
part of CS is an engineering discipline.  But in any case academic CS
is academic.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#20029

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Computer science as academics is a side branch of mathematics, and it
>>shows.
> 
> Theoretical computer science is a branch of mathematics.  The other
> part of CS is an engineering discipline.

Maybe in Austria ;-).  At the TU Munich, the entire "Informatik" is 
considered a branch of mathematics (and historically actually was, until 
they had about 10 times as many students).

> But in any case academic CS is academic.

Hehe.

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

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

#20034

On Feb 22, 5:30 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> I'm talking about Gforth EC, which is a "traditional" all Forth+assembler
> controller Forth.  It reuses the Forth part of Gforth (slimmed down a bit),
> and does the stuff that are primitives in C in a mixture of assembler (real
> primitive) and Forth (replacement code).  The problem with you is that you
> have some emotional reasons against Gforth, and therefore you ignore all
> facts about it.

I had never heard of Gforth EC prior to your mention above. What
threading scheme does it use? What processors is it for? The PIC24? Is
it a cross-compiler or an on-board system?

I have been strongly opposed to Gforth since the moment that I heard
about it. I avoid Gforth like the plague.

I first heard about Gforth from C programmers. When I mentioned that I
program in Forth, and that I think Forth is a better language than C,
this was met with a lot of derisive laughter. I was informed by the C
programmers that Gforth is written in C, which "proves" that C is
superior to Forth --- that Forth is just a toy interpreter similar to
Lua or Python or whatever. I had never even heard of Gforth at that
time. I was told that the "Forth leadership" (that means yourself,
Anton Ertl, etc.) have determined that C is the best language in the
world, which is why they wrote Gforth in C --- of course, the C
community already knows that C is the best language in the world, so
they don't really need you guys to agree with them, although they
think that it is amusing that you do agree with them.

I just ignored Gforth for many many years because I considered Gforth
to be a betrayal of everything that Forth is about. I only recently
downloaded it (after I started visiting c.l.f.) so I could test my
novice package on it --- Gforth has bugs, but I worked around them in
the novice package (this is also true of Win32Forth and SwiftForth,
which are every thing that I've tested so far). I considered using
Gforth as the platform for my cross-compiler, but it has too many
serious problems that will never get fixed, and so it is unsuitable. I
have no intention of ever using Gforth for anything --- I think it is
crap --- it was written by and for C enthusiasts, for the purpose of
promoting C as the "god language" (Rod Pemberton's term). Also, I
think that Gforth was purposely crippled so that it would be slower
than SwiftForth --- because Forth Inc. would have kicked all of you
off the Forth-200x committee if you wrote a publicly-available Forth
system that was faster than SwiftForth --- so you cow-towed to
Elizabeth Rather and crippled Gforth so as not to embarrass her. Forth
Inc. only tolerates the Forth community so long as the Forth community
is willing to suck --- I refused to publicly say that my code sucks,
which is why Elizabeth Rather turned against me --- if I had publicly
sucked, then I would have remained in Elizabeth Rather's good graces
(she would praise me to the sky, just as she does Passaniti) ---
sucking is what comp.lang.forth is really all about.

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

#20036

Hugh Aguilar wrote:

> On Feb 22, 5:30 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> I'm talking about Gforth EC, which is a "traditional" all Forth+assembler
>> controller Forth.  It reuses the Forth part of Gforth (slimmed down a
>> bit), and does the stuff that are primitives in C in a mixture of
>> assembler (real primitive) and Forth (replacement code).  The problem
>> with you is that you have some emotional reasons against Gforth, and
>> therefore you ignore all facts about it.
> 
> I had never heard of Gforth EC prior to your mention above. What
> threading scheme does it use? What processors is it for? The PIC24? Is
> it a cross-compiler or an on-board system?

Gforth EC is an on-board system.  The best-supported Gforth EC port is for 
the R8C, we have some other ports like to the 6502 and the 8086 (16 bit DOS 
program), which aren't tested regularly.  It uses classical indirect 
threading, but well, the threading scheme is actually up to the porter, you 
can also implement direct threading if you want.  Gforth EC requires a 
dozend primitives to get going, and a few more to get to acceptable speed.

> I have been strongly opposed to Gforth since the moment that I heard
> about it. I avoid Gforth like the plague.

You didn't really hear about it.

> I first heard about Gforth from C programmers. When I mentioned that I
> program in Forth, and that I think Forth is a better language than C,
> this was met with a lot of derisive laughter. I was informed by the C
> programmers that Gforth is written in C, which "proves" that C is
> superior to Forth --- that Forth is just a toy interpreter similar to
> Lua or Python or whatever.

Ah.  Well, this explains the bullshit you say about Gforth: You heard it 
from idiots; which explains your distorted view of reality.  They mocked you 
to have some fun.

Gforth (the non-EC-version) uses C as language for the "primitives", instead 
of using assembler.  The majority of Gforth is written in Forth, including 
the generator of the C code for the primitive, because those are actually 
written in "vmgen", a language that does the tedious task to create the C-
based primitives.  Most C people absolutely hate it when we tell them we use 
C as portable assembler.  They say "it's meant to be a high level language" 
- no, it's meant to be a portable assembler, it's absolutely no good at HLL.  
Go is probably the best approach at HLL from the C-like languages, and it 
has several Forthish things in it (multiple return values, fast compiles).

For Gforth EC, we simply leave the C part away, and replace it with hand-
written assemlber and Forth.  If C was such a good language, we couldn't 
easily replace it with pure Forth and assembler, and those big parts of 
Gforth which are written in Forth would be actually written in C, wouldn't 
they?  We probably wouldn't need this vmgen stuff, because writing the 
primitives completely in C would be a piece of cake, no intermediate 
language needed.

> I had never even heard of Gforth at that
> time. I was told that the "Forth leadership" (that means yourself,
> Anton Ertl, etc.) have determined that C is the best language in the
> world, which is why they wrote Gforth in C --- of course, the C
> community already knows that C is the best language in the world, so
> they don't really need you guys to agree with them, although they
> think that it is amusing that you do agree with them.

Each time the C leadership (the GCC compiler team) manages to break Gforth 
for no good reasons other than "this code isn't standard", we curse this 
design decision.  We then yell at Andrew Haley ;-).

> I just ignored Gforth for many many years because I considered Gforth
> to be a betrayal of everything that Forth is about. I only recently
> downloaded it (after I started visiting c.l.f.) so I could test my
> novice package on it --- Gforth has bugs

You know that you should report bugs, because otherwise, they will never get 
fixed.

> , but I worked around them in
> the novice package (this is also true of Win32Forth and SwiftForth,
> which are every thing that I've tested so far). I considered using
> Gforth as the platform for my cross-compiler, but it has too many
> serious problems that will never get fixed

Yes, because you don't report them.  How can we know what kind of problems 
you have if you don't tell us?  We might not listen to you, if your bug 
report is just full of diatribe, but if you can explain what's going wrong 
and what should be the right way to do it, we might see what's wrong.

> , and so it is unsuitable. I
> have no intention of ever using Gforth for anything --- I think it is
> crap --- it was written by and for C enthusiasts, for the purpose of
> promoting C as the "god language" (Rod Pemberton's term).

You are babbling bullshit.  I've killfiled Rod Pemberton a long time ago, 
his bullshit is clearly worse than yours.  I don't think C is a "god 
language".  It is just available everywhere, and helped us to get Gforth 
quickly up and running on the half a dozend RISC chip that were popular back 
when we started.

> Also, I
> think that Gforth was purposely crippled so that it would be slower
> than SwiftForth --- because Forth Inc. would have kicked all of you
> off the Forth-200x committee if you wrote a publicly-available Forth
> system that was faster than SwiftForth ---

Haha.  Again, you are completely uninformed.  Anton Ertl strted the 
Forth200x effort, and it took some years until someone from Forth Inc. came 
over to participate.  Leon Wagner certainly doesn't dominate the Forth200x 
process, he's just one participant and has exactly one vote.  We try to 
reach rough consensus, but Forth Inc. certainly can't veto anything.  Or 
kick anybody out.

Your theory is just crazy.  Gforth's goal is to sacrifice spead over 
portability, but I'm thinking about adding an analytical backend for at 
least x64 and ARM (Anton has the idea to use C to generate the code for less 
popular platforms, but the compile speed will be really slow).  You have 
argued that I can't do that, because it's all written in C, but trust me, 
you are totally wrong here.

> so you cow-towed to
> Elizabeth Rather and crippled Gforth so as not to embarrass her. Forth
> Inc. only tolerates the Forth community so long as the Forth community
> is willing to suck --- I refused to publicly say that my code sucks,
> which is why Elizabeth Rather turned against me --- if I had publicly
> sucked, then I would have remained in Elizabeth Rather's good graces
> (she would praise me to the sky, just as she does Passaniti) ---
> sucking is what comp.lang.forth is really all about.

And so your rant turns against to Elizabeth Rather... come on, poor guy.  It 
helps to be nice to each others.  I wouldn't dare drink a beer with you, 
because I suppose it will soon end in a bar brawl.

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

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

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

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

csiph-web