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 2 of 2 — ← Prev page 1 [2]

#36072

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

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

Yes - and exactly because of this I wasn't asking just about R> - but about
entire "words tree" - and whole "Forth system/kernel" - how this can be built
from ground up.

Well I found some first clues in Brad's Rodriguez text.
-- 
"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]

#36083

On Tuesday, January 27, 2015 at 5:47:37 AM UTC-5, empty-buffers wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
> 
> > 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? 
> > [..]
> 
> Yes - and exactly because of this I wasn't asking just about R> - but about
> entire "words tree" - and whole "Forth system/kernel" - how this can be built
> from ground up.
> 
> Well I found some first clues in Brad's Rodriguez text.
> -- 
> "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".

Brad's work is really excellent to explain the internals of a Forth system. If I read your earlier post correctly I think you are looking for something that may not exist as one treatise, but your question begs for an answer.

To paraphrase I think you are looking for a document that would explain the various trade-offs that occur from the fundamental decisions one makes in building a Forth system:
1 in-direct vs direct vs sub-routine threading vs code-size vs execution speed.
2 Minimum code word set vs maximum code word set
3 dictionary structure affect on compilation speed
4 caching stack elements in registers vs not
etc...

Am I close?

I think what you might be fighting against here is the experienced people have read material over the last 30 years or so that outlined the trade-offs and/or they have built systems and explored the trade-offs such that it is now second nature.

It does provide a good opportunity to created a comprehensive treatise on the topic. I am neither qualified nor am I volunteering, but there must be a student out there in need of thesis. :-)

BF

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

#36084

In comp.lang.forth, foxaudioresearch@gmail.com wrote:

> Am I close?

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

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

#36086

empty-buffers wrote:
> I wasn't asking just about R> - but about entire "words tree" - and
> whole "Forth system/kernel" - how this can be built from ground up.

My toy "lbForth" is based on 16 primitives, in less than 200 lines of
CODE words.  The 360-line kernel is defined in terms of those
primitives, and only contains a bare minimum needed to load and
compile the rest of the system.

I'm not sure this is a good way to understand how a system can be
built.  But it certainly is a small amount of code to read.

(Yes, I'm another bit-twiddling monkey.  Didn't make me a good Forth
programmer.)

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

#36089

On Wednesday, January 28, 2015 at 4:18:45 AM UTC-8, Lars Brinkhoff wrote:
>
> My toy "lbForth" is based on 16 primitives, in less than 200 lines
> of CODE words.  The 360-line kernel is defined in terms of those
> primitives, and only contains a bare minimum needed to load and
> compile the rest of the system.
> 
> I'm not sure this is a good way to understand how a system can be
> built.  But it certainly is a small amount of code to read.
> 
> (Yes, I'm another bit-twiddling monkey.  Didn't make me a good Forth
> programmer.)
>
@empty-buffers:  Ditto.
@Lars:  That sounds interesting.  What is your host processor, what's
 your threading method, and is there a public link to your source?

Thanks,
Mike

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

#36092

Michael Barry <barrym95838@yahoo.com> writes:
> @Lars:  That sounds interesting.  What is your host processor, what's
>  your threading method, and is there a public link to your source?

The bootstrap target (which is the only functional target) uses C
inside the CODE words.  The C target uses indirect threading.  Google
lbForth, and you'll find it on github.

It's not completely undocumented.

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

#36096

Lars Brinkhoff wrote:

> empty-buffers wrote:
>> I wasn't asking just about R> - but about entire "words tree" - and
>> whole "Forth system/kernel" - how this can be built from ground up.
> 
> My toy "lbForth" is based on 16 primitives, in less than 200 lines of
> CODE words.  The 360-line kernel is defined in terms of those
> primitives, and only contains a bare minimum needed to load and
> compile the rest of the system.

If you care to send me a list of the words you include in the very basic 
system then I will add them to my cross-reference list that compares for a 
variety of small Forths's. Happy to send a copy of the comparison table back 
in either Libre-Office, Word or as a pdf. A note about how far you have gone 
in complianc with the standard would also be useful.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#36110

Paul E Bennett wrote:
> If you care to send me a list of the words you include in the very basic 
> system then I will add them to my cross-reference list that compares for a 
> variety of small Forths's.

These primitives are required by the kernel:

\ Definitions:          dodoes exit
\ Control flow:         0branch
\ Literals:             (literal)
\ Memory access:        ! @ c! c@
\ Aritmetic/logic:      + nand
\ Return stack:         >r r>
\ I/O:                  emit open-file read-file close-file

I suppose this could be squeezed a bit by excluding C! and C@.  Also,
I managed to define 0BRANCH and (LITERAL) in terms of other
primitives, but the system became unbearably slow.

> Happy to send a copy of the comparison table back in either
> Libre-Office, Word or as a pdf. A note about how far you have gone
> in complianc with the standard would also be useful.

Thanks, a PDF would be nice.

Running Hayes' CORE tests results in 77 failures (out of how many
tests? I don't know).  I believe many of those are due to a stubbed
UM/MOD.

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

#36097

In comp.lang.forth, Lars Brinkhoff wrote:

>> I wasn't asking just about R> - but about entire "words tree" - and
>> whole "Forth system/kernel" - how this can be built from ground up.
>
> My toy "lbForth" is based on 16 primitives, in less than 200 lines of
> CODE words.  The 360-line kernel is defined in terms of those
> primitives, and only contains a bare minimum needed to load and
> compile the rest of the system.
>
> I'm not sure this is a good way to understand how a system can be
> built.  But it certainly is a small amount of code to read.
>
> (Yes, I'm another bit-twiddling monkey.  Didn't make me a good Forth
> programmer.)

Downloaded - surely analysis of your implementation and being able to
examine its functionality in practice will be valuable source of information.
Thanks!
-- 
"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]

#36099

On Tue, 27 Jan 2015 05:47:36 -0500, empty-buffers  
<empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:

> Yes - and exactly because of this I wasn't asking just about R> - but
> about entire "words tree" - and whole "Forth system/kernel" - how this
> can be built from ground up.
>
> Well I found some first clues in Brad's Rodriguez text.

For interpreted Forth's, they can be built up from a small set of
primitives (or low-level words according to Ms. Rather).  You can
build up a dictionary by storing definitions in the same dictionary
format that interactively defining the words would store them into
memory.  You just need to decide on your dictionary format and have
a way to store all the fields for each definition without using the
inner and outer interpreter.  You can do this using assembly, like
Fig-Forth or Bradford Rodriquez's various Forths, or even in a
high-level language like C as I and others have done.


Rod Pemberton

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

#36106

Op Wed, 28 Jan 2015 20:05:26 -0500 schreef Rod Pemberton:

> On Tue, 27 Jan 2015 05:47:36 -0500, empty-buffers  
> <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> 
>> Yes - and exactly because of this I wasn't asking just about R> - but
>> about entire "words tree" - and whole "Forth system/kernel" - how this
>> can be built from ground up.
>>
>> Well I found some first clues in Brad's Rodriguez text.
> 
> For interpreted Forth's, they can be built up from a small set of
> primitives (or low-level words according to Ms. Rather).  You can
> build up a dictionary by storing definitions in the same dictionary
> format that interactively defining the words would store them into
> memory.  You just need to decide on your dictionary format and have
> a way to store all the fields for each definition without using the
> inner and outer interpreter.  You can do this using assembly, like
> Fig-Forth or Bradford Rodriquez's various Forths, or even in a
> high-level language like C as I and others have done.
> 
> 
> Rod Pemberton

What do yo mean with /interpreted Forth's/ Are you referring to threaded
(indirect or direct)? Every Forth can be extended with new dictionary
entries, that's the nature of the language's (your outer) interpreter.
Inner interpreter is 70's speak and may be called address interpreter, but
only threaded implementations use them. A Forth that generates native code
has no address interpreter.
Every Forth can extend its dictionary, its called compiling. One might do
it by hand like you wrote above where you are your own compiler, but
loading a file is easier, use your Forth computer for that!

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#38903

Am 25.01.2015 um 18:52 schrieb empty-buffers:
> 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.
>

Bradford J. Rodriguez published his articles about writing CamelForth 
for Z80, 8051, 6809, and 8086 that originally appeared in The Computer 
Journal:

http://www.bradrodriguez.com/papers/index.html

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

#36021

On Sun, 25 Jan 2015 02:22:26 -0500, Elizabeth D. Rather  
<erather@forth.com> wrote:
> 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.

That's all fine advice for a novice who is intent on learning forth.

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

I guess you don't recall ...  It came about through another project.
At first, it was just a simple interpreter, not even remotely Forth-like
in C then NASM, both, finally C only.  Next, things progressed over
many years, in starts, stops, various spurts, numerous additions,
rewrites, etc.

> It sounds masochistic.

I've programmed many things without much reason because someone else
requested it, or paid for it, or setup a competition, or because
I wanted to, or because I needed to, or because I need something to
do, or to try out ideas new to me, or because it's a passion or impulse,
or simply because I can, etc.

Deciding to do something code-wise is one of the areas where
programming can be devoid of all logic or reason.  If you want
to call that masochistic, that's fine, but I suspect you've coded
for all those same reasons at some point and perhaps for others.
I.e., I think it's part of the definition of being a computer
programmer.


Rod Pemberton

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

#36001

Julian Fondren wrote:
> 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.

And you can't install the 32 bit 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.

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.

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

#36003

On 1/24/15 1:37 PM, Bernd Paysan wrote:
> Julian Fondren wrote:
>> 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.
>
> And you can't install the 32 bit libraries?

Yes, that would be the answer. SwiftForth works fine with 64-bit Windows 
and OSX (which are what I use).

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]

#36011

Julian Fondren <julian.fondren@gmail.com> writes:
>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.

You could build the wrappers that are built dynamically on the machine
where you built Gforth, and include the stuff in the package.
Configuring with

configure ... LIBCC_BUILD_SRC="mysql.fs sqlite.fs ..."

should do it (I think).

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

#36042

Jason Damisch schrieb:
>>   "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.

:-) I am ! It's a shiny place, we have GPIOs !
... and for some time bit-bang USB on small MSP430.

Matthias

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

#35988

Being a bit-twiddling monkey with a paycheck is better than being a self-congratulater who spends all of his time posting messages on comp.lang.lisp.

I have noticed, btw, that over 95% of the threads on comp.lang.lisp were started by you, and all of them promote Gauche Scheme rather than CL --- don't you have anything better to do with your time? --- have you considered becoming a bit-twiddling monkey as a life-upgrade?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web