[mercury-users] Mercury seems OK on OpenBSD/zaurus

[Julien Fischer]

On Wed, 7 Feb 2007, Julian Fondren wrote:

> (The 'zaurus' part of the subject refers to the Sharp's SL-C3200, of a
> family of clamshell devices with host USB, &c, that OpenBSD targets as
> a platform.  Of interest here: it has one 416MHz processor and 64MB of
> RAM.)
>
> I already knew that boehm GC did not work currently on this arch, so I
> altered configure to only use the 'asm_fast' (no '.gc') grade, and
> then passed `--enable-libgrades=asm_fast` so that it would presumably
> not try anything else.  After this, everything built without any
> difficulty!
>
> So far, things seem OK.  mmc has as nice aspect in that it will
> instantly tell you about errors:
>
> $ time mmc list_test.m
> list_test.m:009: In clause for predicate `list_test.length/2':
> list_test.m:009:   error: ambiguous overloading causes type ambiguity.
> list_test.m:009:   One or more of the predicates or functions called
> list_test.m:009:   is declared in more than one module.
> list_test.m:009:   Try adding explicit module qualifiers.
>     0m6.30s real     0m1.21s user     0m0.64s system
>
> and spends more time on correct code:
>
> $ time mmc hello.m
> # omitting OpenBSD warnings about e.g., sprintf()
>     0m47.43s real     0m7.81s user     0m7.57s system
>
> Although swapping is a very serious issue on this machine, as you can
> see:
>
> 6.30-(1.21+0.64) + 47.43-(7.81+7.57) = 36.50 seconds of swap
>
> Hopefully that issue will clear up some as boehm comes to work on this
> arch and backends like the bytecode one mature.  Anyway, swapping
> hurts less in debugging: repetitions of the first example drop down to
> 2.15s.
>
> As 'mmake' in mercury-tests starts over from the beginning, and I had
> to interrupt the process to get some work done, I only have test failures
> up to the test of `hard_coded/any_call_hoist_bug`, which I interrupted:

I'm a little suprised that you got as far as you did without a garbage
collector.

> $ cat FAILED_TESTS_SUMMARY
> debugger/interpreter in grade asm_fast
> debugger/uci_index in grade asm_fast
> debugger/browser_test in grade asm_fast

Possibly problems caused by (a lack of?) readline.

> debugger/interactive in grade asm_fast

Does dynamic linking work on this platform, e.g. dlopen(), if not that
would be why this test case is failing.

> general/intermod_type in grade asm_fast
> general/mode_inference_reorder in grade asm_fast
> general/string_to_float in grade asm_fast

I would be interested in seeing the log files generated by these tests
and the debugger ones above.

> general/string_format/string_format_o in grade asm_fast

This one fails on a lot of platforms; it's not serious.

Thanks for letting us know about this.

Julien.

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------