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

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

Examples of current implementations in Forth for bachelor thesis

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

Contents

  Examples of current implementations in Forth for bachelor thesis Oliver Bach <decfreak@googlemail.com> - 2013-01-10 17:28 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-10 19:52 -0800
    Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-11 03:35 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-14 15:13 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-14 21:16 -0500
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-15 14:47 -0800
            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-18 23:24 -0500
    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-11 04:08 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Spam@ControlQ.com - 2013-01-11 13:09 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-01-12 11:59 +0100
    Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 07:41 +1300
      Re: Examples of current implementations in Forth for bachelor thesis Chris <xrissmith@me.com> - 2013-01-12 21:05 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 22:26 +1300
    Re: Examples of current implementations in Forth for bachelor thesis gavino_himself <visploveslisp@gmail.com> - 2013-01-13 18:41 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-17 23:42 -0800
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-19 18:21 -0800
        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-20 14:26 +0100
          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-20 10:58 -0600
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-20 15:46 -0800
            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 01:51 -0800
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-21 04:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:45 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:48 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-21 22:01 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 13:42 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 02:18 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 01:06 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Lauri Alanko <la@iki.fi> - 2013-02-01 04:54 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 19:34 -1000
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:32 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-02 18:17 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 17:51 +0000
              Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-21 14:55 +0000
            Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 03:18 -0500
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 01:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 03:31 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 03:41 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:36 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:23 -0600
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:38 -0500
                Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 12:52 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:31 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:35 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 18:22 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 09:40 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 21:02 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 13:30 -0800
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 23:07 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 15:16 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-23 13:07 -0500
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 08:33 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 16:46 -0500
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 23:31 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 18:09 -0500
                                  Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-27 10:15 +0100
                                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-31 14:41 -0500
                                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-31 21:03 +0100
                                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-01-31 21:44 +0200
                                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 23:16 -0800
                                        Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:47 -0800
                                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-02-01 08:23 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 04:48 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 17:30 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:32 -0800
                Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:35 -0500
                  Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:29 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 02:21 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 04:43 -0600
                      Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 03:28 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 09:19 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-23 09:24 -0800
                            Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 12:01 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis David Thompson <dave.thompson2@verizon.net> - 2013-02-04 03:09 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:59 -0500
                      Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 03:05 -0600
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-26 04:38 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-26 07:19 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 13:13 -0600
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 17:00 -0500
                            Re: Examples of current implementations in Forth for bachelor thesis None <vandys@vsta.org> - 2013-01-26 22:04 +0000
              Re: Examples of current implementations in Forth for bachelor thesis kenney@cix.compulink.co.uk - 2013-01-22 18:20 -0600
                Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 23:25 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 03:02 -0600
              Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 18:28 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-25 16:57 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-25 08:41 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:04 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-26 09:25 +1300
                      Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-26 13:16 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-30 18:40 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 15:15 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-31 15:55 +0000
                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-02-24 00:57 +0200
                      Re: Examples of current implementations in Forth for bachelor thesis Brad Eckert <hwfwguy@gmail.com> - 2013-01-31 09:01 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 19:41 +0100
                          Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-01 16:08 +0000
                            Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 02:16 +0000
                              Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:38 +0100
                              Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 14:50 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 00:32 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:39 +0100

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

#19028

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

> IMO, there is no *real* point to either "just-in-time compiling"
> or a VM.

 Byte code interpreters like the Pascal P system or early 
implementations of Java were far easier to port than native code 
compilers and in the case of the P system included an editor and file 
handling also written in Pascal.The problem there was speed as the P 
system was implemented on 8 bit processors. 
 
 Just in time compiling speeds things up and allows programs to be 
distributed as source for maximum portability without the user having to 
compile the program before use. That was a problem I came across when I 
tried Linux years ago and the make files always needed editing because 
the program writer had a different file layout.

 Ken Young

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

#19036

On Jan 23, 12:20 am, ken...@cix.compulink.co.uk wrote:
> In article <kdlhv8$25...@speranza.aioe.org>,
>
> do_not_h...@notemailnotz.cnm (Rod Pemberton) wrote:
> > IMO, there is no *real* point to either "just-in-time compiling"
> > or a VM.
>
>  Byte code interpreters like the Pascal P system or early
> implementations of Java were far easier to port than native code
> compilers and in the case of the P system included an editor and file
> handling also written in Pascal.The problem there was speed as the P
> system was implemented on 8 bit processors.
>
>  Just in time compiling speeds things up and allows programs to be
> distributed as source for maximum portability without the user having to
> compile the program before use. That was a problem I came across when I
> tried Linux years ago and the make files always needed editing because
> the program writer had a different file layout.
>
>  Ken Young

It's even more flexible than that. With a VM you can distribute the
same *object code* (afterall, no commercial vendor wants to distribute
their precious source code) and it will run across many different
platforms.

Java is the perfect example. I can compile Java source into a jar file
and you can run it on Apple, Solaris, Unix, Linux, or Windows.

Of course, the Java byte code is a virtual assembly languge, and
that's where the VM comes in. And the JIT compiler is a feature of the
VM. It compiles (to native machine code) only the code in the
execution path.

As Andrew pointed out, previously compiled code is cached (for want of
a better word) so that it does not need to be compiled again, so it
runs at native speed. Yes, there is a small delay the first time a
particular code path has been encountered, but I have noticed over the
years (in .Net, where I have more experience than Java) that it's been
improving hugely, you don't notice it any more.

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

#19037

kenney@cix.compulink.co.uk wrote:
> In article <kdlhv8$25n$1@speranza.aioe.org>, 
> do_not_have@notemailnotz.cnm (Rod Pemberton) wrote:
> 
>> IMO, there is no *real* point to either "just-in-time compiling"
>> or a VM.
> 
> Byte code interpreters like the Pascal P system or early 
> implementations of Java were far easier to port than native code 
> compilers and in the case of the P system included an editor and file 
> handling also written in Pascal.The problem there was speed as the P 
> system was implemented on 8 bit processors. 

Indeed it was rather slow.  The original idea was for the user either
to write an interpeter or modify the source of the P-compiler and
replace its code-generaring routines.  However, according to Wirth,
"the reluctance of many to proceed beyond the interpretive scheme also
gave rise to Pascal's classification as a 'slow language,' restricted
to use in teaching."

Andrew.


N. Wirth, Recollections about the development of Pascal
HOPL-II
Pages: 97-120  
ISBN:0-201-89502-1 

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

#19109

On Jan 22, 1:18 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
>
> news:ac332281-5f87-463a-8bcd-de34e1cb5f90@t6g2000pba.googlegroups.com...
>
>
>
> > Over on the Racket mailing list, I asked what the point of a VM
> > and just-in-time compiling was, and why not just compile into
> > machine-code (do the hard work at compile-time rather than
> > run-time). I was told (by Stephen Bloch, the guru over there),
> > that the use of a VM allows an executable to run on various
> > processors without being recompiled --- so long as there is
> > a VM for that processor.
>
> Hugh, tell me the truth.  Are you making fun of some of the people
> here?  Unlike me and you, most here can't pick out a craftily
> worded contradiction of logic even if it were to smack them on the
> forehead...  It's probably a factor as to why they're religious.
> Anyway, I'd swear you've posted variations of this little "test"
> at least six times now.  If it's wasn't a test, you might want to
> ask yourself why you keep posting the same thing over and over
> again.

I've never posted any kind of variation on this post before. I had not
considered the idea of inter-processor operability prior to Stephen
Block telling me about it (I had always thought of Java being
primarily for security, but hadn't considered the fact that a VM also
allows for inter-processor operability).

> Obviously, "just-in-time compiling" compiles the code.  So,
> claiming the code executes "without being recompiled" is _clearly_
> an erroneous statement, either on your part or Mr. Bloch's.

I meant that the person distributing the application program doesn't
have to recompile his program. He doesn't have to have versions for
x86, ARM, Power-PC, etc. available, and ask each customer what
processor will be used so he can ship the correct version. After the
customer gets his program, if he should switch to using a different
processor, he only has to make sure he has the correct version of the
VM on his computer --- he doesn't have to upgrade every application
program that he has, but all of them will run unchanged on the new
computer.

Java is a good thing. It allows people to avoid a monopoly in which
the whole world is tied to a single processor manufacturer (Intel).

I don't program in Java. I'm not much interested in learning Java,
mostly because I have read that it lacks closures (it has something
called a "closure," but what it has is not really a closure at all).
I'm learning Scheme instead.

> IMO, there is no *real* point to either "just-in-time compiling"
> or a VM.
>
> A VM is a software version of a processor.  It re-implements
> functionality the processor can already do, typically.  This means
> a VM will always be slower than native code which executes
> directly on the microprocessor.

Not necessarily. Nowadays, optimization is mostly about reducing cache
thrashing. Compiling to machine-code tends to produce bloated code.
This is okay when you are testing with a small benchmark program (the
Sieve or whatever), because the benchmark program fits entirely in the
code cache (32K on the modern x86). With a large program however,
bloat is a problem. With machine-code, there is going to be a lot of
cache-thrashing. If the VM fits in the 32K cache however, then it
doesn't matter how big the program is --- there will be no cache
thrashing at all. JIT is the (supposedly) the best of both worlds. If
you run a benchmark program, after the first few iterations, this
small program will be compiled into machine-code and it will fit in
the cache, so there is no cache thrashing. But the program as a whole
primarily runs as interpreted VM code, so there is no cache thrashing
there either, as the VM fits in the cache.

I'm not going to support JIT with Strate Forth however --- mostly
because JIT is way more complicated than I want to mess with. Strate
Forth is for micro-controllers. Most micro-controllers don't have a
cache anyway, so fitting a VM in cache isn't an issue anyway. Also,
nobody is going to distribute programs to different processors --- all
micro-controller programs are very hardware specific in regard to
their I/O, so inter-processor operability is nonsense in that context
anyway.

The x86 Forth system (HostForth) doesn't have to be very fast. The
only program that runs on it, is the cross-compiler. HostForth can be
a pretty simple TIL and it will be fast enough. I may support inter-
processor operability here, although I won't have a JIT.

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

#19138

Hugh Aguilar wrote:
> Not necessarily. Nowadays, optimization is mostly about reducing cache
> thrashing. Compiling to machine-code tends to produce bloated code.
> This is okay when you are testing with a small benchmark program (the
> Sieve or whatever), because the benchmark program fits entirely in the
> code cache (32K on the modern x86). With a large program however,
> bloat is a problem. With machine-code, there is going to be a lot of
> cache-thrashing. If the VM fits in the 32K cache however, then it
> doesn't matter how big the program is --- there will be no cache
> thrashing at all.

Well, the data cache is not any bigger than the code cache, so there 
will be cache thrashing in the data cache.  And the VM data (which is 
really code) will compete with the real data.

Compilers like VFX or iForth don't inline arbitrary long sequences, and 
also don't unroll loops; their code is pretty compact, more compact than 
a 32 bit ITC, and certainly more compact than a 64 bit ITC.

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

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

#19140

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Compilers like VFX or iForth don't inline arbitrary long sequences, and 
> also don't unroll loops; their code is pretty compact, more compact than 
> a 32 bit ITC, and certainly more compact than a 64 bit ITC.

I was surprised to learn that even 16 bit ITC is not all that compact,
compared with alternatives:

http://lists.canonical.org/pipermail/kragen-tol/2007-September/000871.html

I guess that should have been obvious though, given the frequency
of primitive words (DUP, DROP, +, etc.) which use only 5 bits in a MISC
instead of 16 in an ITC.

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

#19150

Op Fri, 25 Jan 2013 08:41:08 -0800 schreef Paul Rubin:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Compilers like VFX or iForth don't inline arbitrary long sequences, and 
>> also don't unroll loops; their code is pretty compact, more compact than 
>> a 32 bit ITC, and certainly more compact than a 64 bit ITC.
> 
> I was surprised to learn that even 16 bit ITC is not all that compact,
> compared with alternatives:
> 
> http://lists.canonical.org/pipermail/kragen-tol/2007-September/000871.html
> 
> I guess that should have been obvious though, given the frequency
> of primitive words (DUP, DROP, +, etc.) which use only 5 bits in a MISC
> instead of 16 in an ITC.

Perhaps, but the compiler that generates the code would be quite 
complicated. How would such a thing fit in a 16 bit address space, next to 
the generated code?

-- 
Coos

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

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

#19151

On 1/26/13 8:04 AM, Coos Haak wrote:
> Op Fri, 25 Jan 2013 08:41:08 -0800 schreef Paul Rubin:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Compilers like VFX or iForth don't inline arbitrary long sequences, and
>>> also don't unroll loops; their code is pretty compact, more compact than
>>> a 32 bit ITC, and certainly more compact than a 64 bit ITC.
>>
>> I was surprised to learn that even 16 bit ITC is not all that compact,
>> compared with alternatives:
>>
>> http://lists.canonical.org/pipermail/kragen-tol/2007-September/000871.html
>>
>> I guess that should have been obvious though, given the frequency
>> of primitive words (DUP, DROP, +, etc.) which use only 5 bits in a MISC
>> instead of 16 in an ITC.
>
> Perhaps, but the compiler that generates the code would be quite
> complicated. How would such a thing fit in a 16 bit address space, next to
> the generated code?
>

It's a strategy best suited to cross-compilers. But a good 
cross-compiler with easy-to-use umbilical pretty much obviates the need 
for a resident Forth in the target.

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]

#19176

Coos Haak <chforth@hccnet.nl> writes:
>> I guess that should have been obvious though, given the frequency
>> of primitive words (DUP, DROP, +, etc.) which use only 5 bits in a MISC
>> instead of 16 in an ITC.
>
> Perhaps, but the compiler that generates the code would be quite 
> complicated. How would such a thing fit in a 16 bit address space, next to 
> the generated code?

I think of MISC as primarily targeted at hardware implementation.

The software equivalent would be bytecode or token threading.  Typically
the tokens are 8 bits, and interpreters of that sort are very common for
many languages.  Of course it could be done with smaller tokens or
variable-length ones, though the runtime bit-twiddling overhead would be
bad.  Code space even in microcontrollers is at less of a premium these
days than it used to be.

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

#19300

On Jan 25, 8:57 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Well, the data cache is not any bigger than the code cache, so there
> will be cache thrashing in the data cache.  And the VM data (which is
> really code) will compete with the real data.
>
> Compilers like VFX or iForth don't inline arbitrary long sequences, and
> also don't unroll loops; their code is pretty compact, more compact than
> a 32 bit ITC, and certainly more compact than a 64 bit ITC.

It is possible to have 32-bit xt values, even in a 64-bit
implementation. This reduces the size of the threaded code by
approximately half, which lessens data-cache thrashing. Also, literal
values can often be 32-bit rather than 64-bit, which helps. This is
what I'm doing in ToyForth.

This is one reason why I dropped the idea of stack-threading (using
RSP as the Forth IP) --- stack-threading necessarily requires 64-bit
xt values. Another reason why stack-threading isn't as cool as it
appears to be, is that it is necessarily DTC rather than ITC, so I
would have DOCOLON code scattered all over the place, which results in
code-cache thrashing.

I'm still expecting that ToyForth will be 10x faster than Gforth ---
that is my goal.

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

#19313

Hugh Aguilar wrote:
> It is possible to have 32-bit xt values, even in a 64-bit
> implementation.

Or 16 bits.  The engine code in Gforth is ~20kB (and that's because the 
C compiled primitives can be quite large); using a +offset approach, 16 
bits would be completely sufficient to encode a primitive Xt without 
indirection.  As Gforth compiles primitive centric code, and we prefer 
ABI-compatible code words (which have a special caller primitive), only 
the primitive Xts are stored in memory.

> This reduces the size of the threaded code by
> approximately half, which lessens data-cache thrashing. Also, literal
> values can often be 32-bit rather than 64-bit, which helps. This is
> what I'm doing in ToyForth.

You can also compress address literals by making them relative to the 
start of the dictionary.  Then nearly all literals should fit into 32 
bits.

> I'm still expecting that ToyForth will be 10x faster than Gforth ---
> that is my goal.

We'll see.  This would give me an incentive to write an analytical 
compiler ;-).

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

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

#19316

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Hugh Aguilar wrote:
>> This reduces the size of the threaded code by
>> approximately half, which lessens data-cache thrashing. Also, literal
>> values can often be 32-bit rather than 64-bit, which helps. This is
>> what I'm doing in ToyForth.
>
>You can also compress address literals by making them relative to the 
>start of the dictionary.  Then nearly all literals should fit into 32 
>bits.
>
>> I'm still expecting that ToyForth will be 10x faster than Gforth ---
>> that is my goal.
>
>We'll see.  This would give me an incentive to write an analytical 
>compiler ;-).

It's certainly possible to be 10 times faster than Gforth on an
appropriately designed benchmark with a Forth system where the code
takes half the space.  But it's doubtful that this speedup transfers
to applications.  I have yet to see a Forth system that's 10 times
faster on any of the benchmarks in appbench (at least for a decimal
10), so getting a factor of 10 there would be quite an achievement.

- 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 2012: http://www.euroforth.org/ef12/

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

#19972

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Examples of current implementations in Forth for bachelor thesis
[..]
> It's certainly possible to be 10 times faster than Gforth on an
> appropriately designed benchmark with a Forth system where the code
> takes half the space.  But it's doubtful that this speedup transfers
> to applications.  I have yet to see a Forth system that's 10 times
> faster on any of the benchmarks in appbench (at least for a decimal
> 10), so getting a factor of 10 there would be quite an achievement.

As you can see below, VFX is 10 times faster than Gforth, and almost 10 
times faster than gforth-fast, on cd16sim.

On the other benchmarks that I have tested the speed range is more like 
a factor of 6 (a car versus a bicycle).

While taking a closer look at appbench-1.1 I noticed a few interesting
things.

1a) brainless contains some kind of cache. It's playing improves when you
    run the benchmark a few times. The final speed figures are shown.

1b) In brainless, all Forths do about 22,000 nodes and 30,000 evals,
    except iForth64, which does 34,000 nodes and 48,000 evals. I couldn't
    find the reason for this (in limited time), but my hunch is that 
    brainless uses bit/cell or cell in a special way.

2)  fcp ran very slowly on iForth. I found that KEY? is used in a tight
    inner loop. In iForth, KEY? calls usleep() to yield to background 
    processes. This probably invalidates a standard fcp for comparison 
    purposes.

3)  lexex is very slow on iForth64, and iForth32 is much faster than 
    iForth64. Again, I could not really find what is causing this. 
    Lexec defines 64-bit sets when bits/cell is 64, but the total number 
    of cells in a set is proportionally smaller. 

Can anybody come up with a reason for 1b) or 3)?

-marcel

cd16sim
-------
VFX Forth Version: 4.50 [build 3327]     0.858 seconds
iForth32                                 1.046 seconds
iForth64 version 4.0.961                 1.072 seconds
gforth-fast                              8     seconds
gforth                                  12     seconds
Win32Forth Version: 4.2  Build: 0545    24.352 seconds
gforth-itc                              33     seconds
gforth-ditc                             35     seconds

brainless (best of 100 runs, cache warmup?)
---------
VFX Forth Version: 4.50 [build 3327]     0.062 seconds, 22428 nodes (361741 Hz), 30300 evals (488709 Hz)
iForth32                                 0.080 seconds, 21915 nodes (273937 Hz), 29106 evals (363825 Hz)
iForth64 version 4.0.961                 0.119 seconds, 34521 nodes (290092 Hz), 48147 evals (404596 Hz)
gforth-fast                              0.297 seconds, 24066 nodes ( 81030 Hz), 33832 evals (113912 Hz)
gforth                                   0.375 seconds, 21893 nodes ( 58381 Hz), 29051 evals ( 77469 Hz)
Win32Forth Version: 4.2  Build: 0545     0.874 seconds, 22428 nodes ( 26139 Hz), 30300 evals ( 35314 Hz)

fcp
---
VFX Forth Version: 4.50 [build 3327]     0.514 seconds  962296 nps 
iForth32                                 0.827 seconds  575535 nps ( KEY? tamed )
iForth64 version 4.0.961                 0.833 seconds  586765 nps ( KEY? tamed )
gforth-fast                              1.888 seconds  285040 nps 
gforth                                   3.291 seconds  140031 nps 
Win32Forth Version: 4.2  Build: 0545     7.269 seconds   63209 nps 

lexex
-----
VFX Forth Version: 4.50 [build 3327]     3.494 seconds
iForth32                                 4.378 seconds
iForth64 version 4.0.961                 6.741 seconds ( why slower than iForth32? )
gforth-fast                             11.357 seconds
Win32Forth Version: 4.2  Build: 0545    16.614 seconds
gforth                                  18.064 seconds

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

#19318

On Thursday, January 31, 2013 7:15:31 AM UTC-7, Bernd Paysan wrote:
> Or 16 bits.  The engine code in Gforth is ~20kB (and that's because the 
> C compiled primitives can be quite large); using a +offset approach, 16 
> bits would be completely sufficient to encode a primitive Xt without 
> indirection.  As Gforth compiles primitive centric code, and we prefer 
> ABI-compatible code words (which have a special caller primitive), only 
> the primitive Xts are stored in memory.
> 
What is the cost of indirection? That's a table lookup, which I expect to be much cheaper than a jump. If you have 8-bit tokens, the code is even more compact.

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

#19323

Brad Eckert wrote:

> On Thursday, January 31, 2013 7:15:31 AM UTC-7, Bernd Paysan wrote:
>> Or 16 bits.  The engine code in Gforth is ~20kB (and that's because
>> the C compiled primitives can be quite large); using a +offset
>> approach, 16 bits would be completely sufficient to encode a
>> primitive Xt without
>> indirection.  As Gforth compiles primitive centric code, and we
>> prefer ABI-compatible code words (which have a special caller
>> primitive), only the primitive Xts are stored in memory.
>> 
> What is the cost of indirection? That's a table lookup, which I expect
> to be much cheaper than a jump. If you have 8-bit tokens, the code is
> even more compact.

Table lookup doesn't cost much, because the branch is predicted, anyways 
(i.e. it jumps where it thinks it should jump to, and when the table 
lookup delivers "yes, was the right destination", it just continues 
there).  But when you have 8 bit tokens, you are limited to 256 
primitives.

The cost is quite likely the same, an add or a table lookup for x86 CPUs 
is about the same effort.

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

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

#19353

Bernd Paysan <bernd.paysan@gmx.de> writes:
>But when you have 8 bit tokens, you are limited to 256 
>primitives.

Gforth has ~330, of which many are rarely used. It would probably have
very little speed penalty if only the 255 most frequent primitives
were performed with a byte code, and the other 80 were performed with
a two-byte-code-sequence.  I would be more worried about alignment
issues in parameters, but you already have that with the 16-bit
representation (if word width is >16 bits).

- 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 2012: http://www.euroforth.org/ef12/

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

#19363

In article <2013Feb1.170813@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>But when you have 8 bit tokens, you are limited to 256
>>primitives.
>
>Gforth has ~330, of which many are rarely used. It would probably have
>very little speed penalty if only the 255 most frequent primitives
>were performed with a byte code, and the other 80 were performed with
>a two-byte-code-sequence.  I would be more worried about alignment
>issues in parameters, but you already have that with the 16-bit
>representation (if word width is >16 bits).

With WORDS in gForth I count 1860 words. So what are primitives?

>
>- anton
>--

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]

#19372

Albert van der Horst wrote:

> In article <2013Feb1.170813@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>But when you have 8 bit tokens, you are limited to 256
>>>primitives.
>>
>>Gforth has ~330, of which many are rarely used. It would probably have
>>very little speed penalty if only the 255 most frequent primitives
>>were performed with a byte code, and the other 80 were performed with
>>a two-byte-code-sequence.  I would be more worried about alignment
>>issues in parameters, but you already have that with the 16-bit
>>representation (if word width is >16 bits).

Or the 32 bit representation on a 64 bit machine, unless you say 
"literals are usually 32 bits, too".

> With WORDS in gForth I count 1860 words. So what are primitives?

Everything before "image-header".

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

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

#19422

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>With WORDS in gForth I count 1860 words. So what are primitives?

Classically CODE words, like "+".

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

#19499

On Jan 31, 7:15 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > It is possible to have 32-bit xt values, even in a 64-bit
> > implementation.
>
> Or 16 bits.  The engine code in Gforth is ~20kB (and that's because the
> C compiled primitives can be quite large); using a +offset approach, 16
> bits would be completely sufficient to encode a primitive Xt without
> indirection.  As Gforth compiles primitive centric code, and we prefer
> ABI-compatible code words (which have a special caller primitive), only
> the primitive Xts are stored in memory.

Loading on 16-bit boundaries is slow on a 32-bit or 64-bit processor
--- I think that it is best to only compress to 32-bit xt values on
both 32-bit and 64-bit processors (that is what I'm doing).

> > This reduces the size of the threaded code by
> > approximately half, which lessens data-cache thrashing. Also, literal
> > values can often be 32-bit rather than 64-bit, which helps. This is
> > what I'm doing in ToyForth.
>
> You can also compress address literals by making them relative to the
> start of the dictionary.  Then nearly all literals should fit into 32
> bits.

I'm already there on that.

> > I'm still expecting that ToyForth will be 10x faster than Gforth ---
> > that is my goal.
>
> We'll see.  This would give me an incentive to write an analytical
> compiler ;-).

How is it possible to write an analytical compile in a C-based Forth
system??? I think you are stuck with a statically defined VM.

If I'm not 10x, then I will have an incentive to write an analytical
compiler --- what I've got right now is just peephole optimization and
a slew of hopefully-common combos.

It is possible to generate machine-code in an ITC system --- I would
make new primitives on the fly --- essentially have two dictionaries
going at the same time, one for colon words and one for primitives (I
did that in MFX for optimization; plus the MiniForth was Harvard
Architecture, so this was necessary anyway).

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

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

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

csiph-web