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

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

Mecrisp 2.1.6 ARM Linux problem

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

Contents

  Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:40 -0800
    Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 09:54 +0100
      Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-26 01:08 -0800
        Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 10:37 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-26 01:52 -0800
            Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-26 11:22 +0100
              Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-27 12:20 -0800
                Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-12-09 15:04 +0100
                  Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-12-09 23:50 -0800
                    Re: Mecrisp 2.1.6 ARM Linux problem Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-12-10 12:00 +0100
    Re: Mecrisp 2.1.6 ARM Linux problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 09:27 +0000
      Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 01:06 +0100
        Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 18:35 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-27 10:24 -0800
            Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 23:27 +0100
          Re: Mecrisp 2.1.6 ARM Linux problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:19 +0000
            Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-28 17:44 +0100
        Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-28 22:19 -0800
          Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 20:47 +0100
            Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-29 12:13 -0800
              Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 01:37 +0100
                Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-29 19:20 -0800
                  Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 23:29 +0100
                    Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-11-30 18:06 -0800
                      Re: Mecrisp 2.1.6 ARM Linux problem Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-01 23:14 +0100
                        Re: Mecrisp 2.1.6 ARM Linux problem Paul Rubin <no.email@nospam.invalid> - 2015-12-01 20:19 -0800

Page 1 of 2  [1] 2  Next page →

#43808 — Mecrisp 2.1.6 ARM Linux problem

This is under Debian 8 on a Scaleway C1 server (scaleway.com,
or instantcloud.io for half hour online trial).

If I run ./mecrisp-stellaris-linux and type

    5 constant nn
    nn . cr bye

it works fine.  Prints 5 and exits.

If I put the above two lines in a file test.fs and run

   ./mecrisp-stellaris-linux < test.fs

then it crashes with an illegal instruction fault.

I also don't see any way to build the interpreter from source, so I ran
the binary that came in the tarball.  Any chance of some build
instructions and/or scripts?

The Mecrisp interpreter is 3x-5x faster than gforth, which is nice, and
this isn't even the version with the register allocator unless I'm
mistaken.

Any advice?

Thanks!

--Paul

[toc] | [next] | [standalone]

#43817

Dear Paul,

I tried the binary with Cyanogenmod 10 on a tablet with a TI OMAP4430 chip, 
but the Linux and Android support still is on its very first beginnings.

Thank you for the bug report ! I hope I'll find out soon how to interface pipes
in assembly on Linux, but currently the register allocator captures my free time;
I'll be giving a speech on Forth compiler optimisations on the
32. Chaos Communication Congress in Hamburg soon.

There is an assemble bash script which gives you the build instructions:

arm-linux-gnueabi-as -o mecrisp-stellaris-linux.o mecrisp-stellaris-linux.s
arm-linux-gnueabi-ld -o mecrisp-stellaris-linux mecrisp-stellaris-linux.o

This is for crossassembling on a x86 machine, you can replace with Debians
native as and ld when on native ARM platform.

Matthias

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

#43818

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> I tried the binary with Cyanogenmod 10 on a tablet with a TI OMAP4430
> chip, but the Linux and Android support still is on its very first
> beginnings.

Well, it worked well enough to let me start it from the command line and
type at it, so that's a start ;-).

> Thank you for the bug report ! I hope I'll find out soon how to
> interface pipes in assembly on Linux, but currently the register
> allocator captures my free time;

That isn't too difficult, there's a syscall that gives you a pair
of file descriptors.  But pipes aren't particularly needed?

> I'll be giving a speech on Forth compiler optimisations on the
> 32. Chaos Communication Congress in Hamburg soon.

Nice!  Will there be a paper or anything?  Will it be in English?

> There is an assemble bash script which gives you the build instructions:
> arm-linux-gnueabi-as...
> This is for crossassembling on a x86 machine, you can replace with Debians
> native as and ld when on native ARM platform.

Thanks!  I used the native as/ld and it gave me some warning messages
but made an executable.  The same test fails as with the prebuilt binary
but I'll try to look into it.  I've never hacked on ARM asm code before,
so this could be interesting.

If you want to play with a Scaleway server (ARM7 Debian), I'll be happy
to give you an account on mine, or have Scaleway send you an invite so
you can get one of your own (they cost just 3 euro a month).

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

#43821

Hi Paul !

> Well, it worked well enough to let me start it from the command line and
> type at it, so that's a start ;-).

Fine :-) If you wish, the current experimental RA has the same look and feel,
just with more compiler performance under the hood.

> That isn't too difficult, there's a syscall that gives you a pair
> of file descriptors.  But pipes aren't particularly needed?

As far as I understand, standart input and output should flow through
the default input and output file descriptors. I am using them already,
so I am puzzled why redirection, which should be transparent, breaks it.

>> I'll be giving a speech on Forth compiler optimisations on the
>> 32. Chaos Communication Congress in Hamburg soon.
> 
> Nice!  Will there be a paper or anything?  Will it be in English?

A special issue of the German Forth magazine "Vierte Dimension" will
be in print in December; it explains the design under the hood, dictionary
design for Flash memory and the register allocator algorithm. German only.

The talk at 32C3 will be translated by the Congress language team,
so you'll find something for you about at New Years Eve or on the 32C3 
livestream in the days after Christmas.

> Thanks!  I used the native as/ld and it gave me some warning messages
> but made an executable.  The same test fails as with the prebuilt binary
> but I'll try to look into it.  I've never hacked on ARM asm code before,
> so this could be interesting.

IT... deprecated messages, right ? Anything else ?

Everything specific to the Linux port is in
mecrisp-stellaris-2.1.6/mecrisp-stellaris-source/linux
so if you wish to help with development, you can start there.
The terminal.s file would be the most interesting part for you, I think.

If you look at the unusual way I handle memory, keep in mind that this
is designed for microcontrollers with bare flash memory.

> If you want to play with a Scaleway server (ARM7 Debian), I'll be happy
> to give you an account on mine, or have Scaleway send you an invite so
> you can get one of your own (they cost just 3 euro a month).

Thank you ! I would love to have a small account on yours in January.
As Debian and Cyanogenmod have the same basic Kernel syscall interface,
I can do development on my tablet computer, but a cross check with
another machine can be helpful from time to time.

Matthias

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

#43822

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> Fine :-) If you wish, the current experimental RA has the same look
> and feel, just with more compiler performance under the hood.

Yes, I do want to try that, but don't have an easy way to run benchmarks
at the moment, so have stayed with the normal version.

> so I am puzzled why redirection, which should be transparent, breaks it.

Yes, I'm puzzled by this too.

> The talk at 32C3 will be translated by the Congress language team,

This sounds good, I can read German with some difficulty but I don't
have much hope understanding a spoken presentation.

> IT... deprecated messages, right ? Anything else ?

Output is here, pardon the long lines:

    $ ./assemble
    ../common/comparisions.s: Assembler messages:
    ../common/comparisions.s:86: Warning: IT blocks containing more than one conditional instruction are deprecated in ARMv8
    ../common/comparisions.s:133: Warning: IT blocks containing more than one conditional instruction are deprecated in ARMv8
    ../common/deepinsight.s:67: Warning: IT blocks containing more than one conditional instruction are deprecated in ARMv8
    ../common/compiler-flash.s:162: Warning: IT blocks containing more than one conditional instruction are deprecated in ARMv8
    ../common/numberstrings.s:304: Warning: IT blocks containing 16-bit Thumb instructions of the following class are deprecated in ARMv8: Short branches, Undefined, SVC, LDM/STM

> The terminal.s file would be the most interesting part for you, I think.

I'll take a look at it but don't expect too much :).

>> If you want to play with a Scaleway server 
> Thank you ! I would love to have a small account on yours in January.

I just put one on for you and emailed you the login details.  I don't
know if I'll still have it in January but they are easy to spin up and
down.  The only problem is there is currently a shortage of them and of
IP addresses in their data center, so getting one can take a few tries.
They say they are in the process of getting and deploying more of them.

> As Debian and Cyanogenmod have the same basic Kernel syscall interface,
> I can do development on my tablet computer, but a cross check with
> another machine can be helpful from time to time.

The experience on it should be similar to a Raspberry Pi 2 or so.  It's
a 4-core ARM7, 1.3 ghz if I remember right, roughly 1/8th the speed of a
fast x86 on most stuff I've tested.

Paul

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

#43824

> Yes, I do want to try that, but don't have an easy way to run benchmarks
> at the moment, so have stayed with the normal version.

You could use the disassembler to SEE the difference, but this would require
to have the source code feed-in up and running first.

>> so I am puzzled why redirection, which should be transparent, breaks it.
> 
> Yes, I'm puzzled by this too.

A test of the included syscall.txt example on your machine with the
precompiled binary gives:

* Copying in single lines one by one manually: Fine.
* Copying in all lines at once manually: Crash with Illegal instruction.
* Insert on standard input: Crash with Illegal instruction.

Why ? It should be blocking, buffered IO... ?

> The experience on it should be similar to a Raspberry Pi 2 or so.  It's
> a 4-core ARM7, 1.3 ghz if I remember right, roughly 1/8th the speed of a
> fast x86 on most stuff I've tested.

Mecrisp-Stellaris is fine with a 8 MHz "machine", so this is already
way beyond my needs. Thank you !

Matthias

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

#43884

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> You could use the disassembler to SEE the difference, but this would
> require to have the source code feed-in up and running first.

"SEE not found" -- maybe I have to load something for that?  I haven't
looked at the docs much yet, just played with the interpreter a little.

> * Copying in single lines one by one manually: Fine.
> * Copying in all lines at once manually: Crash with Illegal instruction.
> * Insert on standard input: Crash with Illegal instruction.
> Why ? It should be blocking, buffered IO... ?

Interesting observation.  One idea is a buffer overflow, where something
is reading the available chars and then handing them off to the
interpreter, which works ok when there's just a few chars.

I tried assembling with -g and running under gdb, but setting
breakpoints didn't work when I did the obvious thing.  I'll try some
more later.

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

#44159

>> * Copying in single lines one by one manually: Fine.
>> * Copying in all lines at once manually: Crash with Illegal instruction.
>> * Insert on standard input: Crash with Illegal instruction.
>> Why ? It should be blocking, buffered IO... ?
> 
> Interesting observation.  One idea is a buffer overflow, where something
> is reading the available chars and then handing them off to the
> interpreter, which works ok when there's just a few chars.
> 
> I tried assembling with -g and running under gdb, but setting
> breakpoints didn't work when I did the obvious thing.  I'll try some
> more later.

Dear Paul,

a small update: Testing on a Raspberry Pi 2 with the same binary works
flawlessy on inserting source code. Something is different in the Scaleway.

Matthias

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

#44169

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> a small update: Testing on a Raspberry Pi 2 with the same binary works
> flawlessy on inserting source code. Something is different in the Scaleway.

Thanks, that's interesting.  I haven't had a chance to mess with it on
the Scaleway since last time I posted about it, unfortunately.  I wonder
what's going on.  Do you have any general advice about how to debug?

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

#44171

>> a small update: Testing on a Raspberry Pi 2 with the same binary works
>> flawlessy on inserting source code. Something is different in the Scaleway.
> 
> Thanks, that's interesting.  I haven't had a chance to mess with it on
> the Scaleway since last time I posted about it, unfortunately.  I wonder
> what's going on.  Do you have any general advice about how to debug?

The suspect ones are serial_emit and serial_key which are the only points
on which the Forth core gets in contact with the underlying kernel when
receiving source code.

I would try to place breakpoints before and after the swi #0 instruction
in both routines and see if the swi smashes the return stack when you
pipe in source code. Mecrisp-Stellaris should not have invalid opcodes,
as it runs fine sometimes and the terminal has no other execution path.

Maybe a destroyed stack (which might happen if the swi gives back more
than the requested byte, exactly: more than four bytes) could cause
a jump to a place where data or the dictionary header resides, which
of course can give invalid opcodes.

Matthias


@ -----------------------------------------------------------------------------
  Wortbirne Flag_visible, "serial-emit"
serial_emit: @ ( c -- ) Emit one character
@ -----------------------------------------------------------------------------
  push {lr}
  bl pause
 
  push {r0, r1, r2, r3, r4, r5, r7}
 
  push {r6}
  
  movs r0, #1   @ File descriptor 1: STDOUT
  mov  r1, sp   @ Pointer to Message
  movs r2, #1   @ 1 Byte
  movs r7, #4   @ Syscall 4: Write
  swi #0
  
  pop {r6}
 
  pop {r0, r1, r2, r3, r4, r5, r7}
  
  drop
  pop {pc}

@ -----------------------------------------------------------------------------
  Wortbirne Flag_visible, "serial-key"
serial_key: @ ( -- c ) Receive one character
@ -----------------------------------------------------------------------------
  push {lr}
  bl pause
  pushdatos
  
  push {r0, r1, r2, r3, r4, r5, r7}
 
  push {r6}
  
  movs r0, #0   @ File descriptor 0: STDIN
  mov  r1, sp   @ Pointer to Message
  movs r2, #1   @ 1 Byte
  movs r7, #3   @ Syscall 3: Read
  swi #0
  
  pop {r6}
  
  pop {r0, r1, r2, r3, r4, r5, r7}
  
  pop {pc}

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

#43820

Paul Rubin <no.email@nospam.invalid> writes:
>The Mecrisp interpreter is 3x-5x faster than gforth, which is nice, and
>this isn't even the version with the register allocator unless I'm
>mistaken.
>
>Any advice?

Build Gforth from source rather than using the Debian package.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43852

Anton Ertl wrote:

> Paul Rubin <no.email@nospam.invalid> writes:
>>The Mecrisp interpreter is 3x-5x faster than gforth, which is nice, and
>>this isn't even the version with the register allocator unless I'm
>>mistaken.
>>
>>Any advice?
> 
> Build Gforth from source rather than using the Debian package.

Or use the Debian package I built (in 
https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/).

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

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

#43874

Bernd Paysan wrote:

> Anton Ertl wrote:
> 
>> Paul Rubin <no.email@nospam.invalid> writes:
>>>The Mecrisp interpreter is 3x-5x faster than gforth, which is nice, and
>>>this isn't even the version with the register allocator unless I'm
>>>mistaken.
>>>
>>>Any advice?
>> 
>> Build Gforth from source rather than using the Debian package.
> 
> Or use the Debian package I built (in
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/).

Well, I haven't yet uploaded an ARM snapshot, but will so shortly - once my 
ARM board has updated to the latest jessie version ;-).

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

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

#43878

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Well, I haven't yet uploaded an ARM snapshot, but will so shortly -
> once my ARM board has updated to the latest jessie version ;-).

I'd be happy to add an account for you on my Scaleway box.  It is
running jessie.

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

#43887

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Well, I haven't yet uploaded an ARM snapshot, but will so shortly -
>> once my ARM board has updated to the latest jessie version ;-).
> 
> I'd be happy to add an account for you on my Scaleway box.  It is
> running jessie.

To create a good snapshot of Gforth, it requires some non-trivial stuff like 
installing Gerald's patched swig, and a lot of other (trivial, but non-
default) build stuff like texinfo.  The ARM board I have is thumb-only, so I 
can generate an eabihf build.  The good news is that every ARM now can do 
thumb, the bad news is that the gforth disassembler for ARM can't... yet.

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

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

#43896

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Bernd Paysan wrote:
>
>> Anton Ertl wrote:
>> 
>>> Paul Rubin <no.email@nospam.invalid> writes:
>>>>The Mecrisp interpreter is 3x-5x faster than gforth, which is nice, and
>>>>this isn't even the version with the register allocator unless I'm
>>>>mistaken.
>>>>
>>>>Any advice?
>>> 
>>> Build Gforth from source rather than using the Debian package.
>> 
>> Or use the Debian package I built (in
>> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/).
>
>Well, I haven't yet uploaded an ARM snapshot, but will so shortly - once my 
>ARM board has updated to the latest jessie version ;-).

A package built on an older distribution is often more widely runnable
than one built on a newer distribution (unless the package
specifically uses a feature only available in the newer distribution).
Building on a newer distribution typically makes the dependencies more
demanding.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43903

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Well, I haven't yet uploaded an ARM snapshot, but will so shortly - once
>>my ARM board has updated to the latest jessie version ;-).
> 
> A package built on an older distribution is often more widely runnable
> than one built on a newer distribution (unless the package
> specifically uses a feature only available in the newer distribution).
> Building on a newer distribution typically makes the dependencies more
> demanding.

It would have been jessie anyways, that board is only supported by jessie.  
The dependencies are quite generic, only libltdl7 and libffi6 has a version 
in the requirements.  Both are available in sid, too.

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

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

#43927

Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Build Gforth from source rather than using the Debian package.
> Or use the Debian package I built (in 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/).

I download the 0.7.3 tarball from savannah and built on the Scaleway box
(./configure; make; sudo make install).  The make install failed showing
several error messages that I can post if anyone cares.  It produced a
gforth executable but no gforth-fast.  The gforth ran the benchmark in
4.380 seconds, exactly the same as the gforth-0.7.2 from the Debian 8
armhf distro.

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

#43941

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Build Gforth from source rather than using the Debian package.
>> Or use the Debian package I built (in
>> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/).
> 
> I download the 0.7.3 tarball from savannah and built on the Scaleway box
> (./configure; make; sudo make install).  The make install failed showing
> several error messages that I can post if anyone cares.  It produced a
> gforth executable but no gforth-fast.  The gforth ran the benchmark in
> 4.380 seconds, exactly the same as the gforth-0.7.2 from the Debian 8
> armhf distro.

I'm certainly more interested in getting 0.8.0 stable.  If you get the same 
problems with the snapshot, please report.

Which benchmark did you use? onebench.fs? 4.38s for gforth onebench.fs 
sounds reasonable.  I've 4.64s on my board, and 2.80s for gforth-fast.

Not being able to build gforth-fast indicates problems (e.g. with the 
register allocation), and I really hate it to release a small bugfix for 
every single GCC release.  I can do that with the snapshots...

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

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

#43942

Bernd Paysan <bernd.paysan@gmx.de> writes:
> I'm certainly more interested in getting 0.8.0 stable.  If you get the same 
> problems with the snapshot, please report.

OK I'll try.

> Which benchmark did you use? onebench.fs? 4.38s for gforth onebench.fs 
> sounds reasonable.  I've 4.64s on my board, and 2.80s for gforth-fast.

No the benchmark was just the simple loop I mentioned earlier:

    1e8 f>s constant nn
    : test nn 0 do i drop loop ;
    test bye

> Not being able to build gforth-fast indicates problems (e.g. with the 
> register allocation), and I really hate it to release a small bugfix for 
> every single GCC release.  I can do that with the snapshots...

Hmm I didn't examine the error messages.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web