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

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

Don't be a bit-twiddling monkey

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

Contents

  Don't be a bit-twiddling monkey "WJ" <w_a_x_man@yahoo.com> - 2015-01-24 01:14 +0000
    Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-23 20:55 -0500
      Re: Don't be a bit-twiddling monkey Jason Damisch <jasondamisch@yahoo.com> - 2015-01-24 07:52 -0800
        Re: Don't be a bit-twiddling monkey Julian Fondren <julian.fondren@gmail.com> - 2015-01-24 08:42 -0800
          Re: Don't be a bit-twiddling monkey Paul Rubin <no.email@nospam.invalid> - 2015-01-24 09:10 -0800
          Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-24 14:57 -0500
            Re: Don't be a bit-twiddling monkey Julian Fondren <julian.fondren@gmail.com> - 2015-01-24 14:32 -0800
              Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-25 01:37 -0500
                Re: Don't be a bit-twiddling monkey Julian Fondren <julian.fondren@gmail.com> - 2015-01-24 23:32 -0800
                  Re: Don't be a bit-twiddling monkey Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-25 21:23 +0100
            Re: Don't be a bit-twiddling monkey "Elizabeth D. Rather" <erather@forth.com> - 2015-01-24 21:22 -1000
              Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-25 17:52 +0000
                Re: Don't be a bit-twiddling monkey anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-26 14:15 +0000
                  Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-26 19:59 +0000
                  Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-28 22:30 -0500
                Re: Don't be a bit-twiddling monkey albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-26 18:24 +0000
                  Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-26 19:58 +0000
                    Re: Don't be a bit-twiddling monkey "Elizabeth D. Rather" <erather@forth.com> - 2015-01-26 11:27 -1000
                      Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-26 21:52 +0000
                        Re: Don't be a bit-twiddling monkey "Elizabeth D. Rather" <erather@forth.com> - 2015-01-26 18:01 -1000
                          Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-27 10:47 +0000
                            Re: Don't be a bit-twiddling monkey foxaudioresearch@gmail.com - 2015-01-27 19:08 -0800
                              Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-28 12:06 +0000
                            Re: Don't be a bit-twiddling monkey Lars Brinkhoff <lars.spam@nocrew.org> - 2015-01-28 13:18 +0100
                              Re: Don't be a bit-twiddling monkey Michael Barry <barrym95838@yahoo.com> - 2015-01-28 08:14 -0800
                                Re: Don't be a bit-twiddling monkey Lars Brinkhoff <lars.spam@nocrew.org> - 2015-01-28 18:53 +0100
                              Re: Don't be a bit-twiddling monkey Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-28 22:14 +0000
                                Re: Don't be a bit-twiddling monkey Lars Brinkhoff <lars.spam@nocrew.org> - 2015-01-29 08:14 +0100
                              Re: Don't be a bit-twiddling monkey empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-29 00:21 +0000
                            Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-28 20:05 -0500
                              Re: Don't be a bit-twiddling monkey Coos Haak <chforth@hccnet.nl> - 2015-01-29 03:33 +0100
                Re: Don't be a bit-twiddling monkey Bernd Linsel <bl1@gmx.com> - 2015-05-09 02:15 +0200
              Re: Don't be a bit-twiddling monkey "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-01-25 17:35 -0500
          Re: Don't be a bit-twiddling monkey Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-25 00:37 +0100
            Re: Don't be a bit-twiddling monkey "Elizabeth D. Rather" <erather@forth.com> - 2015-01-24 21:08 -1000
          Re: Don't be a bit-twiddling monkey anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-25 15:36 +0000
        Re: Don't be a bit-twiddling monkey Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-26 17:24 +0100
    Re: Don't be a bit-twiddling monkey hughaguilar96@gmail.com - 2015-01-23 21:56 -0800

Page 1 of 2  [1] 2  Next page →

#35981 — Don't be a bit-twiddling monkey

Re: Help understanding closures

Kent M. Pitman wrote:

> > I believe that I understand closures conceptually.  They are rather
> > simple.  They are just a capture of the lexical environment in which a
> > function is created, so as to provide bindings for free variables.
> >
> > What I am confused about is the implementation of a closure.  I'm
> > hoping you guys can help me out.
> 
> This is a bad plan, btw.
> 
> Lisp is a language which deliberately hides implementation from you because
> you are not supposed to have to know.  You will not become a better Lisp
> programmer by seeking the answer to this question; you will become a better
> compiler writer, perhaps.  But although Lisp can implement itself, one does
> not prove one's merit in Lisp by doing so.  You can solve a lifetime of
> application problems in Lisp without ever knowing the answer to these
> questions, and there is indeed no single answer to the question you ask,
> any more than there is a single answer to "what internal data structure is used
> when you sort something?" or "how are the hash keys of an arbitrary
> hash table computed?"  You are inquiring about something for which there
> is a lot known, and about which you can learn a lot, but it won't get you
> closer to "understanding closures", just like "understanding the chemistry
> of food additives" probably won't make you a better judge of whether to buy
> coke or pepsi for an upcoming party you're hosting...

[toc] | [next] | [standalone]

#35985

On Fri, 23 Jan 2015 20:14:52 -0500, WJ <w_a_x_man@yahoo.com> wrote:

> Re: Help understanding closures
>
> Kent M. Pitman wrote:

No, he didn't.  At least, not here he didn't say that.  Is that even
remotely a proper sentence?  Sorry, I really don't even care ...

>> > I believe that I understand closures conceptually.  They are rather
>> > simple.  They are just a capture of the lexical environment in which a
>> > function is created, so as to provide bindings for free variables.
>> >
>> > What I am confused about is the implementation of a closure.  I'm
>> > hoping you guys can help me out.
>>
>> This is a bad plan, btw.
>>
>> Lisp is a language which deliberately hides implementation from you
>> because you are not supposed to have to know.  You will not become
>> a better Lisp programmer by seeking the answer to this question;
>> you will become a better compiler writer, perhaps.  But although
>> Lisp can implement itself, one does not prove one's merit in Lisp
>> by doing so.  You can solve a lifetime of application problems in
>> Lisp without ever knowing the answer to these questions, and there
>> is indeed no single answer to the question you ask, any more than
>> there is a single answer to "what internal data structure is used
>> when you sort something?" or "how are the hash keys of an arbitrary
>> hash table computed?"  You are inquiring about something for which
>> there is a lot known, and about which you can learn a lot, but it
>> won't get you closer to "understanding closures", just like
>> "understanding the chemistry of food additives" probably won't
>> make you a better judge of whether to buy coke or pepsi for an
>> upcoming party you're hosting...

Apparently, this is from the third post in thread "Help understanding
closures" 3/10/2003 by Justin Dubs on comp.lang.lisp.

https://groups.google.com/d/msg/comp.lang.lisp/F7zOw-HBfZY/KvjarFOQ7cAJ

Hey, WooJuice, we didn't get the "woo" because we're not on the "juice"!

So, uh, why are you posting quoted replies to ANCIENT LISP threads?
Are you using Google Groups?  Not good.  Really, not good ...

Or, did you have something to say other than the subject line:

  "Don't be a bit-twiddling monkey"

There was a conversation on closures here a while ago.
You could've added this to that thread.


Rod Pemberton

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

#35994

>   "Don't be a bit-twiddling monkey"

Here he is over clipping his posts and being confusing, again.

*DO* be a bit-twiddling monkey.  It's a awesome skill to be able
to bit bang I/O. I'd rather have carnal knowledge than be left in
the dark.

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

#35995

KMP: You are inquiring about something for which there is a
lot known, and about which you can learn a lot, but it won't
get you closer to "understand closures".

Likewise, you can find exchanges in clf where one person will
say "I'm implementing a forth so that I can better understand
Forth" and people will point out that this is not exactly a
direct route.  Or even a certain route: people have managed
to implemented forths without learning Forth.

There's no admonishion there against bit-twiddling, nor here
against implementing forths.  WJ is learning the lessons he's
setting out to learn.

Meanwhile, my Forth-on-CGI project has hit a speed bump that
would benefit greatly from some bit twiddling (that I cannot
provide):

1. SwiftForth is a 32-bit Forth.  My webhost uses a 64-bit
Linux - and consequently, 64-bit libraries, such as the
libraries you must use to communicate with MySQL or SQLite.
SwiftForth can't use those libraries.

2. I have a 64-bit Gforth build, but its FFI involves
compilation and those tools (libtool, gcc, etc.) aren't
available, so I can't use those libraries with it either.

I've fallen back to using popen2 with 'mysql' (the binary).
The overhead of this method makes PHP more competitive, so
I'm also having to stop and consider a variety of DB-less
alternatives.


-- Julian

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

#35996

Julian Fondren <julian.fondren@gmail.com> writes:
> 1. SwiftForth is a 32-bit Forth.  My webhost uses a 64-bit
> Linux... I have a 64-bit Gforth build, but its FFI involves
> compilation and those tools (libtool, gcc, etc.) aren't
> available, so I can't use those libraries with it either.

Why don't you use a VPS instead of a webhost?  There are some
ridiculously cheap ones these days, especially if you're ok with
a shared ipv4 address like you get with cheap webhosting.

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

#35999

On Sat, 24 Jan 2015 11:42:08 -0500, Julian Fondren  
<julian.fondren@gmail.com> wrote:

> KMP: You are inquiring about something for which there is a
> lot known, and about which you can learn a lot, but it won't
> get you closer to "understand closures".
>
> Likewise, you can find exchanges in clf where one person will
> say "I'm implementing a forth so that I can better understand
> Forth" and people will point out that this is not exactly a
> direct route.

As one in that position, it's more like "I'm implementing a forth
and I'm learning forth along the way, even though I don't care to
learn that much about forth" and people here will point out that
you don't need to understand how forth works in order to program
in forth therefore learning how forth works is useless. Which,
I think is somewhat absurd ...  At least, that's my grasp on what
others here have tendency to say.

> Meanwhile, my Forth-on-CGI project has hit a speed bump that
> would benefit greatly from some bit twiddling (that I cannot
> provide):

I'm assuming that neither of the two issues below have anything
to do with your "Forth-on-CGI".  I'm assuming you mentioned them
because you're looking for alternate method to bypass the
"speed bump" in your forth.  Is that correct?  Or, is your
"Forth-on-CGI" coded for Swiftforth or GForth?

> 1. SwiftForth is a 32-bit Forth.  My webhost uses a 64-bit
> Linux - and consequently, 64-bit libraries, such as the
> libraries you must use to communicate with MySQL or SQLite.
> SwiftForth can't use those libraries.

I'm not familiar with Swiftforth.

What do you mean by "can't use"?  I.e., what is the actual problem?
Why can't Swiftforth use those libraries?

E.g., I could assume that you mean you "can't use" the libraries
because they're 64-bit and Swiftforth is 32-bit and you don't know
how to use 32-bit values to create 64-bit values.  Or, I could
assume that may SwiftForth doesn't have an FFI to the libraries.
But, as to which assumption, if either, is correct, I can't tell.
Of course, one can make many other assumptions too.

> 2. I have a 64-bit Gforth build, but its FFI involves
> compilation and those tools (libtool, gcc, etc.) aren't
> available, so I can't use those libraries with it either.

Ok.

> I've fallen back to using popen2 with 'mysql' (the binary).
> The overhead of this method makes PHP more competitive, so
> I'm also having to stop and consider a variety of DB-less
> alternatives.

It seems popen2() is listed as deprecated.  Should you be using it?
https://docs.python.org/2/library/popen2.html

My I assume your "Forth-on-CGI" is coded in Python?  I.e., since
you're using popen2() ...

If so, what is the actual "speed bump"?  ISTM, you haven't actually
mentioned it yet ...  I.e., if you mention it, maybe someone here
can help.

If not, i.e., coded for Swiftforth or GForth, how did you get access
to an FFI for Python without the tools to compile?  e.g., built-in?
Does Python have other FFIs built-in?  e.g., to access C?


Rod Pemberton

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

#36000

On Saturday, January 24, 2015 at 11:10:48 AM UTC-6, Paul Rubin wrote:
> Why don't you use a VPS instead of a webhost?  There are some
> ridiculously cheap ones these days, especially if you're ok with
> a shared ipv4 address like you get with cheap webhosting.

Everyone targets the VPS, essentially.  Even PHP.  Shared
hosting is a non-thought or an afterthought or only thought
of by shared hosting companies, and if anyone asks for how
they can improve on their shared hosting situation, answer #1
is "huh? Well, step one, get off shared hosting so that you
can use *any* of the technologies people have been coming up
for the last several decades, none of which were conceived of
in the context of a shared hosting environment."

And yet, shared hosting is extremely popular.  So there's
more of an opportunity for Forth to be competitive, there.

On Saturday, January 24, 2015 at 1:57:22 PM UTC-6, Rod Pemberton wrote:
> Or, I could
> assume that may SwiftForth doesn't have an FFI to the libraries.

SwiftForth's FFI fails on 64-bit libraries.  Does SwiftForth
not need to be 64-bit itself to work with 64-libraries?  I
dunno.  This is bit-twiddling.

> It seems popen2() is listed as deprecated.  Should you be using it?
> https://docs.python.org/2/library/popen2.html
> ...
> My I assume your "Forth-on-CGI" is coded in Python?

*facepalm*

popen() is a POSIX function that lets you communicate with a
subprocess on your choice of stdin or stdout.  popen2(), and
popen3(), as named by every single person who has approached
the problem ever, not just Python people, are non-POSIX
functions that allow you to communicate with a subprocess on
on *both* stdout and stdin or on *all* of stdout, stdin, and
stderr.

Basically, you use dup2() in a child process to replace stdin
and stdout (and stderr) with the ends of a pipes before
exec()ing.  

To use the 'mysql' binary for access to MySQL, I thought
popen2() was needed because the only secure way to pass a
password to it was through stdin.  I ended up using a
defaults file to pass the password, and stdin to pass the
(possibly quite long) query.


-- Julian

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

#36002

On Sat, 24 Jan 2015 17:32:17 -0500, Julian Fondren  
<julian.fondren@gmail.com> wrote:

> popen() is a POSIX function that lets you communicate with a
> subprocess on your choice of stdin or stdout.  popen2(), and
> popen3(), as named by every single person who has approached
> the problem ever, not just Python people, are non-POSIX
> functions that allow you to communicate with a subprocess on
> on *both* stdout and stdin or on *all* of stdout, stdin, and
> stderr.

Can't you do that with any child process?  Aren't all open
file descriptors which includes stdin, stdout, stderr,
inherited by child processes for fork() or spawn() or system()?
I know they are for DOS.  For DOS, this is limited to the
first twenty.

> Basically, you use dup2() in a child process to replace
> stdin and stdout (and stderr) with the ends of a pipes
> before exec()ing.

This I understand.  DOS doesn't have popen().

> To use the 'mysql' binary for access to MySQL, I thought
> popen2() was needed because the only secure way to pass a
> password to it was through stdin.  I ended up using a
> defaults file to pass the password, and stdin to pass the
> (possibly quite long) query.

I would *assume* (since I've never done this ...) that you
could write directly to stdin from the parent, _if_ the
child inherits open file descriptors.

I'm not sure if that is any more or less secure than a pipe.
The pipe probably hides output from being displayed on the
terminal, but it's contents are probably not encrypted and
present in memory or on disk.

Or, perhaps, you could open an additional file to use as
a private stdin since it should be shared/inherited,
perhaps a tmpfile() which is typically implemented in memory.

You might look for a get character function which doesn't
echo (display) the character on stdout.  E.g., DOS has
DOS specific get character functions which don't echo.
Although, I'm not sure if Linux or POSIX does ...  It might
be available as a terminal control sequence instead.

Do you control the method that the database is accessed to
eliminate the need for the password or change the process?


Rod Pemberton

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

#36005

On Saturday, January 24, 2015 at 5:37:19 PM UTC-6, Bernd Paysan wrote:
> And you can't install the 32 bit libraries?

As an unprivileged user without a C compiler?  Yeah, probably, but
the larger problem is that these libraries are probably specific to a
version of MySQL.  I could hack a single account into a working state;
I couldn't offer someone else a reasonable way to set up their own
shared account.

> You can compile the interfaces on your development system, and copy them 
> over to your target system; if Gforth finds a library in the right place 
> (and with the right sourcecode hash in the development version), it takes 
> that instead of trying to compile again.
> 
> E.g. if you want to use the pthread bindings, those two files will be loaded 
> (the first is just containing metadata): 
> 
> /usr/local/lib64/gforth/0.7.9_20141031/libcc-named/libgfpthread.la
> /usr/local/lib64/gforth/0.7.9_20141031/libcc-named/libgfpthread.so.0
> 
> You find the results of this compilaton on your development system in
> 
> ~/.gforth/amd64/libcc-named/
> 
> and you have to adjust the path in the .la file (last entry) so that it 
> fits.

Hmm, alright, I'll try this sometime.



On Sunday, January 25, 2015 at 12:37:49 AM UTC-6, Rod Pemberton wrote:
> On Sat, 24 Jan 2015 17:32:17 -0500, Julian Fondren  
> <julian.fondren@gmail.com> wrote:
> 
> > popen() is a POSIX function that lets you communicate with a
> > subprocess on your choice of stdin or stdout.  popen2(), and
> > popen3(), as named by every single person who has approached
> > the problem ever, not just Python people, are non-POSIX
> > functions that allow you to communicate with a subprocess on
> > on *both* stdout and stdin or on *all* of stdout, stdin, and
> > stderr.
> 
> Can't you do that with any child process?  Aren't all open
> file descriptors which includes stdin, stdout, stderr,
> inherited by child processes for fork()

Yes, but without the elaborate preparation that popen2() and popen3()
take care of, the inherited fds are the parent's own, and aren't
useful for communication between the parent and child.

> or spawn() or system()?

Sure, although fds can be flagged CLOSE_ON_EXEC

> Do you control the method that the database is accessed to
> eliminate the need for the password or change the process?

I don't understand this question.  I'm *providing* a method to access
the database, so that CGI scripts can access it.


-- Julian

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

#36019

Julian Fondren wrote:

> On Saturday, January 24, 2015 at 5:37:19 PM UTC-6, Bernd Paysan wrote:
>> And you can't install the 32 bit libraries?
> 
> As an unprivileged user without a C compiler?

Of course you have to build them somewhere else, but LD_LIBRARY_PATH allows 
you to access libraries in whatever dictionary you have access to.

> Yeah, probably, but
> the larger problem is that these libraries are probably specific to a
> version of MySQL.  I could hack a single account into a working state;
> I couldn't offer someone else a reasonable way to set up their own
> shared account.

Or you just ship that specific version of MySQL with the rest of the 
stuff...

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#36004

On 1/24/15 9:57 AM, Rod Pemberton wrote:
> On Sat, 24 Jan 2015 11:42:08 -0500, Julian Fondren
> <julian.fondren@gmail.com> wrote:
>
>> KMP: You are inquiring about something for which there is a
>> lot known, and about which you can learn a lot, but it won't
>> get you closer to "understand closures".
>>
>> Likewise, you can find exchanges in clf where one person will
>> say "I'm implementing a forth so that I can better understand
>> Forth" and people will point out that this is not exactly a
>> direct route.
>
> As one in that position, it's more like "I'm implementing a forth
> and I'm learning forth along the way, even though I don't care to
> learn that much about forth" and people here will point out that
> you don't need to understand how forth works in order to program
> in forth therefore learning how forth works is useless. Which,
> I think is somewhat absurd ...  At least, that's my grasp on what
> others here have tendency to say.

I use a lot of things I couldn't possibly build, and only have a general 
idea of how they work: computers, for example; my iPhone; my car. Most 
excellent pianists couldn't possibly build a piano. It is quite possible 
to learn how to write excellent Forth applications without understanding 
all the internals, and certainly without building one.

I don't mean to discourage anyone from writing their own Forth. It's 
just that the most successful path is:

1. Learn how to use Forth to write programs. Keep at it until you're 
comfortable and your programs are pretty clean. You will then understand 
how Forth is used.

2.  Dig further into the internals, by reading the source of the Forth 
you use (as well as its documentation). You will then understand how 
Forth works.

3. If you *then* want to write a Forth from scratch (either for a new 
platform or just for the fun of it), you will find it a much more 
rewarding and satisfying project. And what you produce will be much 
better than anything you could have written before.

I have some trouble understanding the motivation you describe as "I'm 
implementing a forth and I'm learning forth along the way, even though I 
don't care to learn that much about forth." It sounds masochistic.

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]

#36013

I wonder does there exist any publicly available "paper" or something,
which describes an example of implementation procedure? I mean from the
very beginning: how it should be started at all, how the "tree of words"
grows (which words should be necessarily programmed in ML, and which ones
can be composed using the former ones as the basis) etc.

Say, we've got some simple system - it can be Arduino with Atmega 328P. Or
it can be TI's Launchpad with MSP430 (or just old IBM XT _without_ DOS). So
we know the hardware, we can find description of its assembler. What next?

No, I don't expect to read "quick Forth implementation course" as reply -
just maybe some links, where could I find more to the subject? Actually all
I could find were some strips of information - like that there are 3 basic
"models" of implementation - but it's not that easy to glue it all together.

And yes: I'm more interested in "standalone Forth" ("close to metal"), than
"hosted" one.
-- 
"Yes, this is the bad end you've come to, and two and two is - as it always
was..." - began Trurl, but just then the machine made a faint, barely audible
croaking noise and said, for the last time: "SEVEN".

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

#36040

empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> writes:
>I wonder does there exist any publicly available "paper" or something,
>which describes an example of implementation procedure? I mean from the
>very beginning: how it should be started at all, how the "tree of words"
>grows (which words should be necessarily programmed in ML, and which ones
>can be composed using the former ones as the basis) etc.

<http://www.bradrodriguez.com/papers/moving1.htm> might be of interest
to you.

Some alternatives:

@Article{kogge82,
  author = 	 "Peter M. Kogge",
  title = 	 "An Architectural Trail to Threaded-Code Systems",
  journal =	 ieeecomputer,
  year =	 "1982",
  pages =	 "22--32",
  month =	 mar,
  annote =	 "Explains the design of (a classical
		  implementation of) Forth, starting with threaded
		  code, then adding the parameter stack, constants,
		  variables, control structures, dictionary, outer
		  interpreter and compiler."
}

Threaded Interpretive Languages: Their Design and Implementation
R. G. Loeliger
McGraw Hill Higher Education (January 1981)

- 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 2014: http://www.euroforth.org/ef14/

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

#36049

Thanks!
-- 
"Yes..." [cut]

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

#36107

On Mon, 26 Jan 2015 09:15:32 -0500, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> Threaded Interpretive Languages: Their Design and Implementation
> R. G. Loeliger
> McGraw Hill Higher Education (January 1981)
>

Of course, you may need to buy it via Amazon, or go to a
large publicly library or university library to find a copy.
Perhaps, an inter-library loan program will send one to
your local library.

Apparently, it's available as an e-book via Scribd.com. (?)

I'm not a member, so I couldn't download it as a .pdf.
But, you can read the book as scanned images on scribd:

http://www.scribd.com/doc/19746809/Threaded-Interpretive-Languages-Their-Design-and-Implementation

My quick scan indicates much of the info in the book is
available in Rodriquez's series or the classic Fig-Forth
documentation.  The book appears to be for a Z80.

This post by me has links to the Fig-Forth documentation
as well as two other decent articles on implementing Forth:

https://groups.google.com/d/msg/comp.lang.forth/hpXUECDU7RE/ZA4wit2xg2oJ


Rod Pemberton

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

#36044

In article <slrnmcabae.9ig.empty.buffersYOU-DONT-WANT-THIS@Ferrycy.localdomain>,
empty-buffers  <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> wrote:
>I wonder does there exist any publicly available "paper" or something,
>which describes an example of implementation procedure? I mean from the
>very beginning: how it should be started at all, how the "tree of words"
>grows (which words should be necessarily programmed in ML, and which ones
>can be composed using the former ones as the basis) etc.

It's unlikely that such paper exists. Nobody implements a Forth in that way.
E.g. ciforth version 0.0 was in fact another (assembler) Forth: fig forth.
Forth that are metacompiled contain swats of existing code.
How would you start to describe an "implementation procedure" for the
word R> that moves a data item from one stack to another?

Or could one manage to waste words on

    : MOD /MOD DROP ;
    : /   /MOD NIP ;

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]

#36048

In comp.lang.forth, Albert van der Horst wrote:

> How would you start to describe an "implementation procedure" for the
> word R> that moves a data item from one stack to another?

I believe if it's possible to do it - then it's also possible to describe
the way it has been done?
-- 
"Yes, this is the bad end you've come to, and two and two is - as it always
was..." - began Trurl, but just then the machine made a faint, barely audible
croaking noise and said, for the last time: "SEVEN".

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

#36059

On 1/26/15 9:58 AM, empty-buffers wrote:
> In comp.lang.forth, Albert van der Horst wrote:
>
>> How would you start to describe an "implementation procedure" for the
>> word R> that moves a data item from one stack to another?
>
> I believe if it's possible to do it - then it's also possible to describe
> the way it has been done?
>

It's normally done in code or the implementation language.

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]

#36060

In comp.lang.forth, Elizabeth D. Rather wrote:

>>> How would you start to describe an "implementation procedure" for the
>>> word R> that moves a data item from one stack to another?
>>
>> I believe if it's possible to do it - then it's also possible to describe
>> the way it has been done?
>>
>
> It's normally done in code or the implementation language.

Hardly a "description", I think. Well anyway, my original question wasn't
about R> implementation in particular.
-- 
"Yes, this is the bad end you've come to, and two and two is - as it always
was..." - began Trurl, but just then the machine made a faint, barely audible
croaking noise and said, for the last time: "SEVEN".

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

#36067

On 1/26/15 11:52 AM, empty-buffers wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
>
>>>> How would you start to describe an "implementation procedure" for the
>>>> word R> that moves a data item from one stack to another?
>>>
>>> I believe if it's possible to do it - then it's also possible to describe
>>> the way it has been done?
>>>
>>
>> It's normally done in code or the implementation language.
>
> Hardly a "description", I think. Well anyway, my original question wasn't
> about R> implementation in particular.
>

What's to describe? R> pops the top of the return stack to the data 
stack. Exactly what this entails depends on the implementation. Is the 
return stack pointer a variable? a register? If it's a register, which? 
All the same questions apply to the data stack. There exists the 
standard description of what the word does, and a very large number of 
possible ways to do it, even on the same processor. So, you can describe 
the way it's done on *this* implementation on *this* processor, but 
what's the value of that? The easiest way to find out how a particular 
application works is to get it and look at its source.

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web