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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#20095

Bernd Paysan wrote:
> Gforth EC requires a dozend primitives to get going

Which are those?  (I did look at the source code, but it was not
obvious to me which the minimal set of primitites are.  Maybe I didn't
find the right place.)

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

#20100

Lars Brinkhoff wrote:

> Bernd Paysan wrote:
>> Gforth EC requires a dozend primitives to get going
> 
> Which are those?  (I did look at the source code, but it was not
> obvious to me which the minimal set of primitites are.  Maybe I didn't
> find the right place.)

Well, AFAIK all implementations go significantly above minimum set.  The 
minimum set IIRC is

execute ;s dodoes @ ! + and xor 0= sp@ rp@ sp! rp!

You can look into prim, nearly all primitives have a replacement definition 
in Forth.  Those are "non-primitive".

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

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

#20116

On Feb 26, 7:11 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > 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 never heard of the R8C either. That is a hybrid processor, with 16-
bit registers but an 8-bit bus? Both the 6502 and 8086 are obsolete.

All of this stuff seems to be not exactly cutting edge. You're riding
Rocinante into the future!

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

VMGEN is a macro language that generates C source-code?

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

I was looking at C-- at one time. It seems to have died though. I was
told that they lost their funding.

Go might be interesting. I have the book on Erlang and it looked
interesting. Go seems to be addressing the same problem. There is a
limit to how much a single processor can do, and we have to be getting
close nowadays --- so the next thing to do is figure out how to use
multiple processors at the same time.

I'm just working on my language now though, so I don't really want to
delve into learning any other language.

BTW, I've changed the name of it from ToyForth to CAMForth. CAM will
be my "killer app." That, plus numerical programming in general.

I am confident that I will be 10x faster than Gforth --- in numerical
programming anyway. I have said many times that it is a mistake for
Forth to try to be good at everything --- you become a jack of all
trades and a master of none. ANS-Forth and Forth-200x lack a lot of
support for numerical programming. You don't have PARABOLA in the
standard, for example. You have to write words like that in high-level
Forth --- if they were in the standard, then they could be written in
assembly-language (or, for Gforth, in C). You are assuming that the
optimizing compiler will always generate fast code --- but it is
actually a lot easier just to write what is important in assembly-
language as primitives, rather than write a super-smart optimizer and
expect it to do the job for you.

In CAM, it is very common to use a lathe to make a reflective surface
for a light. I've done this myself with ceramic when I was working as
a machinist. A fast PARABOLA is important for CAM, so I'm
standardizing the word. That and a lot of other common numerical
functions.

Besides that, even though I only have a high-school education, I think
I know a lot more about numerical programming than anybody at Forth
Inc. does. This is an example of SwiftForth code (why does Forth Inc.
make their source-code available when it is this bad???):

: FEXPM1 ( r -- r )   FEXP #1.0E F-  ;
\ (e to the x) - 1

: FLNP1 ( r -- r )   #1.0E F+ FLN  ;
\ ln(x+1)

That looks like something that Wally from the Dilbert cartoon might
write. A no-brainer!

ANS-Forth and Forth-200x don't have D/ either. Most likely, this is
because nobody at Forth Inc. could figure out how to write it. I have
it in my novice package in the CF.4TH file. It is somewhat
complicated. This, btw, is the only file in the package that I didn't
write myself. Low-level functions such as this should be in the
standard however, so they can be written in assembly-language --- the
version in the novice package is written in ANS-Forth and hence is
very slow.

Forth is actually a good language for numerical programming, but I've
never heard of any Forth being oriented toward numerical programming
--- CAMForth should be the first.

I can't think of any other killer-app than CAM. If I do think of one
though, then I will write a Forth that is customized to that app.
Chuck Moore purportedly said: "Standards are very important ---
everybody should have one!"

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

Can Forth-200x be the "standard" Forth if SwiftForth isn't Forth-200x
compliant? I don't think so --- Forth Inc. owns the word "Forth."

If you don't cow-tow to Forth Inc., then Forth-200x will be no
different from CAMForth --- a non-standard Forth --- except that
Forth-200x won't have any features and won't be particularly good for
any application, and CAMForth will.

Also, Leon Wagner killed my ALLOCATION without even reading it (he
said that it had nothing to do with lists, although that was the only
example that I gave, so he obviously hadn't read it at all), and
without getting any consensus from anybody. He does have veto power!
There was support for it from several people until he killed it, then
everybody started pretending that they had been against it all along
so that they wouldn't appear to have ever contradicted Forth Inc.. The
primary argument offered against it was that GLIBC doesn't support it,
and Gforth etc. all rely on GLIBC for the heavy lifting, so they can't
have any features that GLIBC doesn't have.

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

#20126

On Thu, 28 Feb 2013 19:37:02 -0800 (PST), Hugh Aguilar
<hughaguilar96@yahoo.com> wrote:

>Also, Leon Wagner killed my ALLOCATION without even reading it (he
>said that it had nothing to do with lists, although that was the only
>example that I gave, so he obviously hadn't read it at all), and
>without getting any consensus from anybody. He does have veto power!

Total rubbish. I was at that meeting.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20129

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Thu, 28 Feb 2013 19:37:02 -0800 (PST), Hugh Aguilar
><hughaguilar96@yahoo.com> wrote:
>
>>Also, Leon Wagner killed my ALLOCATION without even reading it (he
>>said that it had nothing to do with lists, although that was the only
>>example that I gave, so he obviously hadn't read it at all), and
>>without getting any consensus from anybody. He does have veto power!
>
>Total rubbish. I was at that meeting.

SIZE (Hugh made an RfD for that, not for ALLOCATION) never made it
into the CfV stage, so it never came up for a decision in committee.
We may have discussed it, but probably not very long; IMO the email
discussion said it all.

- 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]

#20332

On Mar 1, 6:52 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> stephen...@mpeforth.com (Stephen Pelc) writes:
> >On Thu, 28 Feb 2013 19:37:02 -0800 (PST), Hugh Aguilar
> ><hughaguila...@yahoo.com> wrote:
>
> >>Also, Leon Wagner killed my ALLOCATION without even reading it (he
> >>said that it had nothing to do with lists, although that was the only
> >>example that I gave, so he obviously hadn't read it at all), and
> >>without getting any consensus from anybody. He does have veto power!
>
> >Total rubbish. I was at that meeting.
>
> SIZE (Hugh made an RfD for that, not for ALLOCATION) never made it
> into the CfV stage, so it never came up for a decision in committee.
> We may have discussed it, but probably not very long; IMO the email
> discussion said it all.

Now you say that it wasn't discussed very long, and that the email
discussion "said it all" --- that is, said that it sucked, and that it
had zero support, and that it indicated a complete failure to
understand Forth on my part --- is there anything else that "said it
all" implies?

At the time, the only technical objection given was from you, and it
didn't seem like much of an objection:

* For those of us who currently implement ALLOCATE by calling C's
malloc() (e.g., Gforth), implementing this functionality would
entail quite a bit of work, and is unlikely to happen soon. But
since it would be an optional word, that's not a big problem.

Other than this one issue about Gforth etc. depending upon GLIBC, I
don't remember any technical objection. Several people thought that my
name SIZE wasn't very descriptive, which I agreed with. The suggestion
was: ALLOCATION for the size originally given to ALLOCATE, or
ALLOCATED for the size actually provided by ALLOCATE (usually rounded
up to a paragraph boundary). I said that either would be fine, and
since ALLOCATED is easier to implement that should be it. I only want
it for the purpose of supporting CLONE-NODE which needs to know how
big the new node should be and how much data to copy over --- I don't
care if the new node is slightly larger than the nominal size of the
node --- the only harm done is copying over a tail containing garbage,
but that is only a few bytes (<16) so it is not affecting the speed at
all. All in all, everything seemed to be moving ahead toward ALLOCATED
getting accepted, which would have been slightly different than what I
proposed (SIZE aka ALLOCATION), but that would have been fine by me.

You seemed to agree with this. You said the following (note that your
term "mainstream systems" means Gforth, and its reliance on GLIBC is
your own fault and nobody else's):

On Tue, Feb 02, 2010 at 02:26:52PM -0800, Leon Wagner wrote:
> If you used ALLOCATED and went beyond the ALLOCATION amount, you would deserve whatever happens to you, IMO.

And what should that be? IMO, if the system lies to the program and
tells that it has given it more memory than it actually has given it,
it's the system's fault. But if the system is truthful, nothing bad
should happen when the program uses everything that the system has
given to the program.

[Stephen Pelc writes:]
> > After the recent flurry, it seems that we need two additional
> > words:
> > ALLOCATION (what was requested)
> > ALLOCATED (what you got)

It certainly helps in the discussion, but I don't think we need both
in the standard. ALLOCATION would be relatively expensive to
implement (and would hurt every ALLOCATE), whereas the idea of
ALLOCATED is to give you information that the system is storing
anyway. So I don't think we should standardize ALLOCATION. ALLOCATED
has the potential for being a sometimes-useful word without the kind
of cost of ALLOCATION, but given that a number of mainstream systems
find it hard to implement, I am pessimistic that it will be widely
implemented and used.

OTOH, since we have already a pretty good idea about what it should be
and a name for it, it may be a good idea to write all of this down in
an RfD, so if some systems ever implements it, there is some guidance
on what to do.

> > ALLOCATED requires more code and memory for
> > every allocation to solve an occasional problem.

No, that information is stored in the system already, for use by FREE
and RESIZE, so no additional memory is needed for ALLOCATED. It does
need some additional code, but if you have access to the internals of
the heap implementation, it should be pretty cheap to implement.

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

#20645

On 3/1/2013 5:56 AM, Stephen Pelc wrote:
> On Thu, 28 Feb 2013 19:37:02 -0800 (PST), Hugh Aguilar
> <hughaguilar96@yahoo.com>  wrote:
>
>> Also, Leon Wagner killed my ALLOCATION without even reading it (he
>> said that it had nothing to do with lists, although that was the only
>> example that I gave, so he obviously hadn't read it at all), and
>> without getting any consensus from anybody. He does have veto power!
>
> Total rubbish. I was at that meeting.
>
> Stephen

So much garbage in Hugh's post that I'm surprised you could limit your 
reply to just this.  I guess he got under your skin.

-- 

Rick

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

#20148

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:3c13cf75-5d0b-4cd9-9aec-1a616e262241@m9g2000pby.googlegroups.com...
> On Feb 26, 7:11 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:

> > 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.
> >
> VMGEN is a macro language that generates C source-code?

Sigh, Hugh, let me ask you a question.  Which Forth's are *not*
written in C?  Or, weren't once?  Which don't use C for
"primitives"?  Of those, how many are still in-use today?  I
would've thought you picked up _something_ from my constant pro-C
writings by now, my constantly mentioning Forths coded in C, etc.
Long-term success doesn't just happen.  There is a reason for it.
Forth is as ubiquitous as C is.  Do you honestly think that
happened without Forth being carried by C on it's back, at least
part of the way?  Don't you think the "Footprints in the Sand"
poem describes C perfectly as a 'God' language:

http://llerrah.com/footprints.htm

> > [Bernd's typical C flamebait snipped]
>
> I was looking at C-- at one time. It seems to have died though.
> I was told that they lost their funding.
>
> Go might be interesting. I have the book on Erlang and it looked
> interesting. Go seems to be addressing the same problem.

I think using C--, Go, Erlang, Lua, Perl, Ruby, etc is clearly a
mistake.  Many languages are "dead".  Many more are going to
"die".  If you code in one of these languages instead of a
language people actually use, your code will be or become "dead"
too.  The exception is if your code is worth millions of dollars
to someone else...

> I am confident that I will be 10x faster than Gforth --- in
> numerical programming anyway.

You can use a calculator to compute faster than Gforth?
Oh, [It] not [I] ...

> I have said many times that it is a mistake for Forth to try to
> be good at everything --- you become a jack of all
> trades and a master of none.

Fortran is very good at one thing and is a horrid language.  COBOL
is very good at one thing and is a horrid language.  Both are dead
languages.  Basic is an effective language.  It's still alive.
It's one of the more general-purpose programming languages in
terms of all-around capabilities.  But, it's not as powerful as
others.  C is far more powerful and also very general-purpose.  C
is very succesful.  PL/I is just as powerful as C, but it's
difficult to implement.  I could continue with a half-dozen other
languages like Pascal, Logo, etc, but I see no point.

Given the history of successful programming languages, do you you
think becoming a "master" will make your language a success or
condemn it to die?

> You are assuming that the optimizing compiler will always
> generate fast code --- but it is actually a lot easier just to
> write what is important in assembly- language as primitives,
> rather than write a super-smart optimizer and expect it to do
> the job for you.
>

Without an optimizer, you can't create the most optimal code over
very long code sequences.

> In CAM, it is very common to use a lathe to make a reflective
> surface for a light. I've done this myself with ceramic when I
> was working as a machinist. A fast PARABOLA is important
> for CAM, so I'm standardizing the word. That and a lot of other
> common numerical functions.

Ok, now your language has a purpose, something that could set it
apart from other languages: CAM.

But, you're not "standardizing" anything by yourself.  You might
be "including" it or "implementing" it in your language.

> Besides that, even though I only have a high-school education, I
> think I know a lot more about numerical programming than anybody
> at Forth Inc. does.

(Is there some deception involved here ... ?)

> This is an example of SwiftForth code (why does Forth Inc. make
> their source-code available when it is this bad???):
>
> : FEXPM1 ( r -- r )   FEXP #1.0E F-  ;
> \ (e to the x) - 1
>
> : FLNP1 ( r -- r )   #1.0E F+ FLN  ;
> \ ln(x+1)
> [code]
>
> That looks like something that Wally from the Dilbert cartoon
> might write. A no-brainer!

Wally's job is secure, yes?

Maybe, they took maintenance programmers into account?

I didn't check.  Do those map directly onto x87 instructions?

What's "bad" about it exactly? (non-working? bad style?
incomplete?)


Rod Pemberton

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

#20153

Can't resist a few answers to your questions.

On 3/1/2013 4:36 PM, Rod Pemberton wrote:
...
> ... Which Forth's are *not*
> written in C?  Or, weren't once?  Which don't use C for
> "primitives"?  Of those, how many are still in-use today?

Well, Chuck has never used C, which means that none of the original 
Forths had anything to do with C. He did write a very early Forth in 
Fortran back in the 60's, though.

Since Chuck was a founder of FORTH, Inc., none of our Forths have ever 
been written in anything other than Forth (and assembler, also written 
in Forth). And these are still very much in use today.

...
>> This is an example of SwiftForth code (why does Forth Inc. make
>> their source-code available when it is this bad???):
>>

Don't bother worrying about Hugh's assaults on SwiftForth. His copy is a 
2.x version. We're on 3.4.5 now. 3.0 came out in 2006.

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]

#20161

Elizabeth D Rather <erather@forth.com> writes Re: Integer cosine function
[..]
>> ... Which Forth's are *not*
>> written in C?  Or, weren't once?  Which don't use C for
>> "primitives"?  Of those, how many are still in-use today?

[ FORTH Inc,'s products ]

Win32Forth, ciforth, CHforth, SP-Forth, Vfx, iForth, tForth,
JonesForth, Power Mops, iMops, BigForth, eForth, ByteForth, 
8052-ANS-Forth, noForth, ...

AFAIK, the only non-toy Forth that uses C (as an assembly language)
is gForth. 

-marcel

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

#20173

In article <kgrohp$j0s$1@speranza.aioe.org>, 
do_not_have@notemailnotz.cnm (Rod Pemberton) wrote:

> Fortran is very good at one thing and is a horrid language.  COBOL
> is very good at one thing and is a horrid language.  Both are dead
> languages.  

 Could you define a dead language? Programs  written in both of those 
languages are still in use and still maintained. 

 Ken Young

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

#20042

On Tuesday, February 26, 2013 12:22:45 AM UTC-7, Hugh Aguilar wrote:
> it was written by and for C enthusiasts, for the purpose of
> promoting C as the "god language" (Rod Pemberton's term). 

Apparently the God of Deuteronomy.

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

#20050

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:eee0b2aa-c5f5-4303-86f3-6bfcadc9fa73@ru10g2000pbc.googlegroups.com...
> [...]
> I avoid Gforth like the plague.

Huh?  You can't avoid the plague.  That's why it's called the
plague.  Duh!

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

Indeed, as you should've been.

> I was informed by the C programmers that Gforth is written in C,
> which "proves" that C is superior to Forth [...]

Yes.  Obviously...

> [...] --- that Forth is just a toy interpreter similar to
> Lua or Python or whatever.

Oh, I doubt they said that.

However, that is a nice embellishment on the continous
re-interpretation and re-posting of this perpetual rant of yours.
I guess you went through another mental re-boot ...

> [...]
> 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 --- [...]

Ah, I think *you* concluded that.

> [...] of course, the C community already knows that C is the
> best language in the world, [...]

Exactly.

> [...] 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.

Quite likely, that's true too.

> I just ignored Gforth for many many years because I considered
> Gforth to be a betrayal of everything that Forth is about.

What would that - "everything that Forth is about" - be exactly?

Describe the betrayal to us.  If you "had never even heard of
Gforth at that time," why do you feel betrayed now?

> [...] Gforth has bugs, [...]

I'm sure someone here would be interested in knowing what
those are exactly.  Do you intend to charge them, or just keep it
a secret?

> [...] I have no intention of ever using Gforth for anything
> [...]

Why would you?  You wrote your "own" Forth and you've got your
"novice package" to promote.  Well, you don't actually own your
Forth, Testra does ...  Sorry, dude:  "... do not pass Go, do not
collect $200".  "Game over man!"  There is only one way forward:
start over.  Well, actually, there are two: hope for Testra to go
bankrupt and buy your Forth back.

> [...] [Gforth] was written by and for C enthusiasts, [...]

Did you just call Anton Ertl, Bernd Paysan, et. al.,
C enthusiasts?  LOL!  Well, if you *did* mean that ...

> [...] [Gforth] was written by and for C enthusiasts, [...]

Yeah, I seriously doubt they are/were C enthusiasts, ever.  I've
seen their C code.

> [...] [Gforth was written] for the purpose of promoting C
> as the "god language" [...]

Oh, I seriously doubt that.  As you stated previously, C
programmers don't give a hoot about Forth.  Why would they need
Forth to promote C?  There are a dozen more complicated
languages implemented in C too.  They - the Gforth authors -
just needed a portable backend.  Assembly is not portable, i.e.,
more work.  Forth, while it's as ubiquitous as C is, actually
isn't commonly present on the platforms Gforth is written for.
Forth is usually only present on such platforms if John Hayes'
VAX FORTH was ported to it.  You know who he is, yes?
Unfortunately, VAX FORTH is written in C too.  (Stop pretending
you've got me filtered Bernd...  I know you want to respond to
that.  It's just a matter of time before you do.  You can't stay
restrained forever especially given your need to contradict such
truths at every turn.)

> "god language" (Rod Pemberton's term).

Yes, that's how I described C once.  Thanks for including me in
your diatribe.  I'm honored.  BTW, look up diatribe.  I suspect
you're not familiar with it.

Apparently, that was just there to rile up an ignorant non-English
speaking person present who pretends to speak English but insists
on misspelling words intentionally, or so he claims, who also
pretends he "killfiles" people, who also likes to pretend that his
wimpy ass would ever go into a bar and make it out without being
beaten just because he was there.  Well, it worked.  I'm still
honored, because you couldn't have really riled up Bernd *any*
other way...

> Also, I think that Gforth was purposely crippled so that it
> would be slower than SwiftForth [...]

Interesting.  No, really, that's an interesting claim.  In what
way?

I'm assuming this wasn't just part of the rant to justify bashing
Forth-200x and Ms. Rather, but I think that's probably an
incorrect assumption.  So, I'll understand if you don't justify
that claim, as is normal...


Rod Pemberton

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

#20053

In article <kgjb3j$sg0$1@speranza.aioe.org>,
Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
>"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
>news:eee0b2aa-c5f5-4303-86f3-6bfcadc9fa73@ru10g2000pbc.googlegroups.com...
>> [...]
>> I avoid Gforth like the plague.
>
>Huh?  You can't avoid the plague.  That's why it's called the
>plague.  Duh!

Let's get back on topic:

0 34
1 34
2 34
3 34
4 34
5 34
6 34
7 34
8 34
9 34
10 34
11 34
12 34
13 34
14 34
15 64
16 64
17 64
18 64
19 64
20 64
21 106
22 106
23 106
24 106
25 106
26 106
27 106
28 106
29 106
30 76
31 76
32 76
33 76
34 76
35 146
36 146
37 146
38 146
39 146
40 146
41 146
42 104
43 104
44 104
45 134
46 134
47 134
48 134
49 134
50 134
51 134
52 134
53 134
54 134
55 134
56 134
57 134
58 134
59 134
60 104
61 104
62 104
63 146
64 146
65 146
66 146
67 146
68 146
69 146
70 76
71 76
72 76
73 76
74 76
75 106
76 106
77 106
78 106
79 106
80 106
81 106
82 106
83 106
84 64
85 64
86 64
87 64
88 64
89 64
90 34
91 34
92 34
93 34
94 34
95 34
96 34
97 34
98 34
99 34
100 34
101 34
102 34
103 34
104 34
105 -34
106 -34
107 -34
108 -34
109 -34
110 -34
111 -34
112 -34
113 -34
114 -34
115 -34
116 -34
117 -34
118 -34
119 -34
120 -64
121 -64
122 -64
123 -64
124 -64
125 -64
126 -106
127 -106
128 -106
129 -106
130 -106
131 -106
132 -106
133 -106
134 -106
135 -76
136 -76
137 -76
138 -76
139 -76
140 -146
141 -146
142 -146
143 -146
144 -146
145 -146
146 -146
147 -104
148 -104
149 -104
150 -134
151 -134
152 -134
153 -134
154 -134
155 -134
156 -134
157 -134
158 -134
159 -134
160 -134
161 -134
162 -134
163 -134
164 -134
165 -104
166 -104
167 -104
168 -146
169 -146
170 -146
171 -146
172 -146
173 -146
174 -146
175 -76
176 -76
177 -76
178 -76
179 -76
180 -106
181 -106
182 -106
183 -106
184 -106
185 -106
186 -106
187 -106
188 -106
189 -64
190 -64
191 -64
192 -64
193 -64
194 -64
195 -34
196 -34
197 -34
198 -34
199 -34
200 -34
201 -34
202 -34
203 -34
204 -34
205 -34
206 -34
207 -34
208 -34
209 -34

Filter by one LC section for <0.1% distortion.

>
>Rod Pemberton
>
>

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#20055

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in
message news:512d58e7$0$589$e4fe514c@dreader34.news.xs4all.nl...
> In article <kgjb3j$sg0$1@speranza.aioe.org>,
> Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> >"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
> >> [...]
> >> I avoid Gforth like the plague.
> >
> >Huh?  You can't avoid the plague.  That's why it's called the
> >plague.  Duh!
>
> Let's get back on topic:
>

I don't know what your post has to do with anything in this
thread.  From the statement near the end, it seems to have
something to do with an analog audio LC filter.  But, there is no
information on whether it is a high-pass, low-pass, series or
parallel notch, etc.  Just as there is no information on the
circuit configuration, there is no information on the component
values for L and C to determine the cutoff or center frequency.
From the posted numbers, no one knows what's going on, except you.
It's clearly not the output of an "Integer cosine function", which
would actually be on topic.  If the data is plotted, it appears to
be an integer SINE function *plus* another imposed sinewave...
However, the y-axis data should cross the x-axis at 0, 180, 360,
except it crosses at 0, 104.5, 209... assuming y-axis is in
degrees.  At least, post data for a COSINE function next time.

Only the first 8 of the 52 posts in this thread at the time I
replied are actually on-topic.  So, if that's how you feel about
my post, you should've also posted that junk in reply to all your
other c.l.f. friends who replied in this thread:

  Coos, Brad, Bernd, Hugh, Anton, Zbiggy, Mark,
  Gary, rickman, Ms. Rather

It seems you like posting in reply to my posts about being
on-topic.  That's like the third time now.  My posts came after
all those other off-topic posts (43) by the people (10) just
mentioned.  That's everybody in the thread except Marcel and you.
Of those two, Marcel is the only person who remained on-topic for
the entire thread.  So, I'm not sure why you're telling me to get
back on-topic.


Rod Pemberton

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

#20318

Hugh Aguilar wrote:

> --- that Forth is just a toy interpreter similar to
> Lua or Python or whatever.

Lua, Python, Ruby, etc., are not toys.

They have done a lot more data processing than Forth has.
You have the mentality of someone who cannot fathom anything
higher level than programming a device to flush a toilet.

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

#20333

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.

The way that C worked on the 8051, was to hold the current stack-frame
in low-memory and use absolute addressing to get at the locals. For
every function call, the parent's stack-frame was moved to high-memory
and the child's stack-frame was moved into low-memory. Moving the
stack-frame in and out for every function call made function calls
pretty slow. Also, it was impossible to use & to obtain the address of
a local variable --- so the result wasn't really C at all, but was
just a C-like language.

Forth was worse though! In Forth, the parameter stack was low-memory.
Pointers had to be adjusted up and down to get at the data. There were
only 2 pointers though (R0 and R1), so this was a major PITA. All in
all, the 8051's lack of an indexed addressing mode really crippled it.

It might have been possible to write a Forth that stored stack
parameters in absolute locations, so absolute addressing could be
done. This would require an analytical optimizer. I have never heard
of this being done. I don't know if it would be possible or not.

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

#20345

Hugh Aguilar wrote:

> 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.
> 
> The way that C worked on the 8051, was to hold the current stack-frame
> in low-memory and use absolute addressing to get at the locals. For
> every function call, the parent's stack-frame was moved to high-memory
> and the child's stack-frame was moved into low-memory. Moving the
> stack-frame in and out for every function call made function calls
> pretty slow. Also, it was impossible to use & to obtain the address of
> a local variable --- so the result wasn't really C at all, but was
> just a C-like language.

Actually, the Keil compiler does better if there's no recursive call, and 
all the stack frames fit together in low memory.

> Forth was worse though! In Forth, the parameter stack was low-memory.
> Pointers had to be adjusted up and down to get at the data. There were
> only 2 pointers though (R0 and R1), so this was a major PITA. All in
> all, the 8051's lack of an indexed addressing mode really crippled it.

Yes.  If you compare the 8051 to something comparable of that era, e.g. the 
6502, you see how bad it is for implementing a HLL.  The 6502 has a better 
approach at low memory, the zero page: It just is the first 256 bytes of the 
memory map, it is easy to access with single bytes.  And it has indexed 
memory access.

> It might have been possible to write a Forth that stored stack
> parameters in absolute locations, so absolute addressing could be
> done. This would require an analytical optimizer. I have never heard
> of this being done. I don't know if it would be possible or not.

It should be possible with about the same limitations of the Keil compiler: 
Cross-compilation only (because it won't fit into the 8051), and no 
recursive functions.

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

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

#20362

On Mar 6, 8:39 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > The way that C worked on the 8051, was to hold the current stack-frame
> > in low-memory and use absolute addressing to get at the locals. For
> > every function call, the parent's stack-frame was moved to high-memory
> > and the child's stack-frame was moved into low-memory. Moving the
> > stack-frame in and out for every function call made function calls
> > pretty slow. Also, it was impossible to use & to obtain the address of
> > a local variable --- so the result wasn't really C at all, but was
> > just a C-like language.
>
> Actually, the Keil compiler does better if there's no recursive call, and
> all the stack frames fit together in low memory.

I don't remember now which C compiler I had looked at. That was a long
time ago. If the Keil system could have more than one stack-frame in
low-memory at the same time, that would help a lot.

When I first started at Testra (actually, during the job interview) I
suggested that I write a Forth compiler for the 80c320, which was the
processor that they were using for motion-control. I think they were
using the Laboratory MicroSystems' Forth cross-compiler (I know they
were using UR/Forth on the desktop computers). My idea was to map all
of the parameters into absolute locations in low-memory for speed. I
also thought that I could examine the entire program to determine
which functions were never in the same execution chain, and allow them
share memory slots without any conflict. This idea was nixed because
the problem with the 80c320 was that integer multiplication was too
slow, and there is no clever solution to that. It was also a problem
that the Forth system was too slow, but they had already converted
pretty much the entire program into assembly-language anyway, so the
Forth's speed was no longer an issue. Anyway, they built the MiniForth
on the Lattice 1048isp PLD, and I wrote MFX for it --- their motion-
control program got ported over to MFX --- it is the only program that
has ever been written in MFX afaik. Nowadays Anton Ertl refers to
Gforth as the "mainstream system," but I'm not aware of anybody having
ever written a commercial product in Gforth --- so I think the score
is 1 to 0 in my favor. :-)

> > Forth was worse though! In Forth, the parameter stack was low-memory.
> > Pointers had to be adjusted up and down to get at the data. There were
> > only 2 pointers though (R0 and R1), so this was a major PITA. All in
> > all, the 8051's lack of an indexed addressing mode really crippled it.
>
> Yes.  If you compare the 8051 to something comparable of that era, e.g. the
> 6502, you see how bad it is for implementing a HLL.  The 6502 has a better
> approach at low memory, the zero page: It just is the first 256 bytes of the
> memory map, it is easy to access with single bytes.  And it has indexed
> memory access.

My only experience with writing a Forth cross-compiler prior to
Testra, was writing one for the 65c02. This was for an Apple-II
program that did symbolic math (it could find derivatives of
functions, but I never got far enough along to be able to find
integrals). This cross-compiler was based on the ISYS Forth for the
Apple-II --- a lot of the more complicated functions were taken
straight from ISYS (the object code was relocatable if it used the
stack rather than global variables, which it usually did).

The clever trick with ISYS, which I borrowed for my Forth, was to have
a split parameter-stack. Most Forths have a parameter stack with the
high and low bytes of each cell adjacent to each other. Assuming that
the stack-pointer is X, then two INX instructions are needed to drop a
cell from the stack, and two DEX instructions are needed to make room
for a cell on the stack. With the split stack however, the low bytes
of the cells are in one stack and the high bytes of the cells are in
another stack, and the two stacks are $40 bytes apart. You use a
different base address ($0 for the low bytes and $40 for the high
bytes) to get the low or high byte of the value. The clever part here
is that only one INX instruction is needed to drop a cell from the
stack, and only one DEX instruction is needed to make room for a cell
on the stack.

ISYS was a really good Forth --- the guy who wrote that knew what he
was doing. The big problem with ISYS was that it was limited in the
size of the programs that it could compile, because the compiler was
in memory along with the program. I solved that problem by making a
cross-compiler. Also, my compiler generated code that made use of the
banked memory of the Apple-II. I generated code for both banks --- I
had all of the code related to displaying on the screen in one bank,
and all the code that did symbolic math in the other bank, so they
wouldn't conflict with each other. I also wrote a source-level
debugger so that I could single-step through my program. That was a
long time ago. In those days I thought that a debugger, such as used
in C programming, was a good idea. Nowadays I wouldn't bother to write
a debugger, as I no longer think they are very useful. Back in MS-DOS
days, everybody used debuggers (called Soft-ICE) --- nowadays almost
nobody does that, but most modern languages offer interactive
debugging similar to what Forth pioneered (by "modern," I mean
everything other than C).

All in all, the 6502 and its derivatives (the 65c02 in the Apple and
the 6510 in the C64) was a pretty cool processor.

The indirect,X addressing mode was a big waste. It was almost never
used by anybody. All of those instructions should have been something
more useful. For the most part though, the 6502 was a good design ---
it was way better than the 6800 that preceded it --- it offered more
opportunity for writing small tight code than the Z80, although the
Z80 was easier to program by most accounts. The 6809 was better than
both, but it only got used in the Radio Shack Color Computer for home
use, and in various OS9 computers for industrial use --- if Motorola
would have stuck with it, they could have succeeded --- but Motorola
repeatedly introduced new-and-improved processors and forced their
customers to rewrite their programs, which is why everybody just
switched over to the Intel 8051 even though it was hard to program by
most standards.

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

#20368

Hugh Aguilar wrote:
> Nowadays Anton Ertl refers to
> Gforth as the "mainstream system," but I'm not aware of anybody having
> ever written a commercial product in Gforth --- so I think the score
> is 1 to 0 in my favor. :-)

Well, a lot of people use Gforth.  We rarely hear what they do with it.   I 
can assure you that people use Gforth not only for hobbyist work, but also 
for commercial work, in so far as the GPL permits (which is quite a lot, 
since most Forth programs are in-house usage, and no source code has to go 
outside).

Not every development gets out to customers.  Two friends of mine in Munich 
ported Gforth EC once to Siemens' latest smart card processor, which didn't 
have a really working C compiler at that time.  The port was a success, they 
had played Tetris for terminals on the processor while the C people still 
were struggling with Hello World.  But in fact, this didn't help the 
smartcard processor from Siemens, which never became a commercial product.  
People rather use these 8051-based smartcards...

> The clever trick with ISYS, which I borrowed for my Forth, was to have
> a split parameter-stack. Most Forths have a parameter stack with the
> high and low bytes of each cell adjacent to each other. Assuming that
> the stack-pointer is X, then two INX instructions are needed to drop a
> cell from the stack, and two DEX instructions are needed to make room
> for a cell on the stack. With the split stack however, the low bytes
> of the cells are in one stack and the high bytes of the cells are in
> another stack, and the two stacks are $40 bytes apart. You use a
> different base address ($0 for the low bytes and $40 for the high
> bytes) to get the low or high byte of the value. The clever part here
> is that only one INX instruction is needed to drop a cell from the
> stack, and only one DEX instruction is needed to make room for a cell
> on the stack.

Nice trick, indeed.  However, you can't access the stack through sp@ + @.

> All in all, the 6502 and its derivatives (the 65c02 in the Apple and
> the 6510 in the C64) was a pretty cool processor.

A lot of people got first contact with computers having that processor in 
it.

> The indirect,X addressing mode was a big waste. It was almost never
> used by anybody. All of those instructions should have been something
> more useful. For the most part though, the 6502 was a good design ---
> it was way better than the 6800 that preceded it --- it offered more
> opportunity for writing small tight code than the Z80, although the
> Z80 was easier to program by most accounts. The 6809 was better than
> both, but it only got used in the Radio Shack Color Computer for home
> use, and in various OS9 computers for industrial use --- if Motorola
> would have stuck with it, they could have succeeded --- but Motorola
> repeatedly introduced new-and-improved processors and forced their
> customers to rewrite their programs, which is why everybody just
> switched over to the Intel 8051 even though it was hard to program by
> most standards.

I've said that the 8051 is what people who stick to what they have done for 
the last 30 years like.  Motorola quickly went from the 6809 to the 68HC11, 
and *that one* lasted.  It is AFAIK still in production, even from the 
original vendor (which is now called Freescale), though it's of course a 
legacy product.  It is available as synthesizable core, for today's typical 
deeply embedded silicon stuff.

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

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

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

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

csiph-web