Forum comments in chronological order

Anonymous
Tue 10-Sep-2019 11:31

Fantastic, and well deserved. Every part of Dialog oozes quality. —Thore

Anonymous
Mon 16-Sep-2019 11:52

I just tried a hello world example and segfaulted the compiler (Dialog, release 0h/02, library 0.30, prebuilt for Linux x64)

$ cat test.dg
(story ifid) B0E2A7D1-45F7-46A1-8348-53ADA71F2CD8
(program entry point)
We'll find out how this works, slowly.

$ valgrind dialogc test.dg
==14539== Memcheck, a memory error detector
==14539== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14539== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14539== Command: dialogc test.dg
==14539==
==14539== Invalid read of size 1
==14539== at 0x12A4FA: addstr_escape.constprop.1 (in /usr/local/bin/dialogc)
==14539== by 0x12AE3D: emit_blorb (in /usr/local/bin/dialogc)
==14539== by 0x129FF1: backend_z (in /usr/local/bin/dialogc)
==14539== by 0x10D487: main (in /usr/local/bin/dialogc)
==14539== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14539==
==14539==
==14539== Process terminating with default action of signal 11 (SIGSEGV)
==14539== Access not within mapped region at address 0x0
==14539== at 0x12A4FA: addstr_escape.constprop.1 (in /usr/local/bin/dialogc)
==14539== by 0x12AE3D: emit_blorb (in /usr/local/bin/dialogc)
==14539== by 0x129FF1: backend_z (in /usr/local/bin/dialogc)
==14539== by 0x10D487: main (in /usr/local/bin/dialogc)
==14539== If you believe this happened as a result of a stack
==14539== overflow in your program's main thread (unlikely but
==14539== possible), you can try to increase the size of the
==14539== main thread stack using the --main-stacksize= flag.
==14539== The main thread stack size used in this run was 8388608.
==14539==
==14539== HEAP SUMMARY:
==14539== in use at exit: 613,930 bytes in 657 blocks
==14539== total heap usage: 1,170 allocs, 513 frees, 1,450,866 bytes allocated
==14539==
==14539== LEAK SUMMARY:
==14539== definitely lost: 7,600 bytes in 50 blocks
==14539== indirectly lost: 206,966 bytes in 102 blocks
==14539== possibly lost: 0 bytes in 0 blocks
==14539== still reachable: 399,364 bytes in 505 blocks
==14539== suppressed: 0 bytes in 0 blocks
==14539== Rerun with --leak-check=full to see details of leaked memory
==14539==
==14539== For counts of detected and suppressed errors, rerun with: -v
==14539== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Anonymous
Mon 16-Sep-2019 11:57

This seems to be linked to the (default) zblorb format. The others work fine.

Anonymous
Tue 17-Sep-2019 19:42

hackernews sent me here

Anonymous
Tue 17-Sep-2019 19:46

Q is dead...#Anastasius

Anonymous
Tue 17-Sep-2019 21:23

so what?

lft
Linus Åkesson
Wed 18-Sep-2019 10:44

Thanks for reporting it!

This appears to happen for small input (i.e. without the standard library), in combination with the zblorb format. I'll fix it tonight. Meanwhile, either switch to the z8 format or include the standard library.

lft
Linus Åkesson
Thu 19-Sep-2019 06:01

This is now fixed in 0h/03.

Anonymous
Mon 23-Sep-2019 12:13

Using dialogc-0h03:

The following program crashes the compiler, regardless of the output format. It works on version 0d02.

(program entry point)
(now) ~($ has parent $)

Error messages:
backend_z.c:2010: generate_code: Assertion `ci->oper[0].value != DYN_HASPARENT' failed.
and
backend_aa.c:1350: compile_routines: Assertion `ci->oper[0].value != DYN_HASPARENT' failed.

--------------------------------------------------------

The following three programs crash the compiler when compiling for the Aa-machine but work fine on the Z-machine:

(program entry point)
(#a = $X)

Error message:
backend_aa.c:752: encode_dest: Assertion `0' failed.

--------------------------------------------------------

Note: I have been unable to minimize this program further because removing any line will cause the crash to disappear.

(program entry point)
($x = 3)
($y = 3)
($ = $)
([#a #b] = [#a #b])
([#a #b] = [#b #a])
([1 [@a] 3] = [1 [@a] 3])
([1 [@a #b] 3] = [2 [@a #b] 3])
([1 [@a #b] 3] = [1 [@a #b] 3])
([1 2 3 4] = [$a $b $c $d])

Error message:
backend_aa.c:3151: opersize: Assertion `aao.value <= 0x3f' failed.

--------------------------------------------------------

And a similar program, also as simplified as possible:

(program entry point)
($x = 3)
($y = 3)
($ = $)
([#a] = [])
([#a #b] = [#a #b])
([#a #b] = [#b #a])
([1 [#a #b] 3] = [1 [#a #b] 3])
([1 [#a #b] 3] = [2 [#a #b] 3])
([1 [#a #b] 3] = [1 [#a #b] 3])
([1 [#a #b] 3] = [1 [#a] 3])

Error message:
backend_aa.c:3151: opersize: Assertion `aao.value <= 0x3f' failed.

lft
Linus Åkesson
Mon 23-Sep-2019 21:36

Thanks! I'll look into these. The first two are corner cases that I hadn't thought of; they should be easy to fix.

The last two happen because the compiler is running out of registers for holding temporary values. Fixing this involves a more substantial implementation effort that I've been putting off. But it needs to be done, of course.

Anonymous
Tue 24-Sep-2019 03:54

lucid explanation. much makes sense on terminals in stevens/kerrisk linux api guide

thanks!

Anonymous
Mon 30-Sep-2019 12:12

Amazing work Linus. I'm especially impressed at how you're proficient with coding, music and graphics all in one.

Just one question. Is the BASIC bootstrap part only necessary because of the competition rules? The Revision rules say "No autostart or assembler jumps/SYS". I guess that rule just means your program needs to be launchable by LOAD, RUN not LOAD, SYS?

Anonymous
Mon 30-Sep-2019 13:50

I have found several possible mistakes in the Aa-machine specification 0.2:

Important differences between the specification and the JS reference implementation:
- IF_FLAG, IFN_FLAG, SET_FLAG, and RESET_FLAG: "1 <<" should be "0x8000 >>" (that is, the spec starts shifting from the least-significant bit, but the ref impl starts shifting from the most-significant bit)
- JMPL_MULTI: "SIM = 0" should be "SIM = 0xffff"
- JMP_TAIL: "SIM < 0x8000" should be "SIM >= 0x8000"
- UNLINK, SET_PARENT: seven occurrences of "value - 1" should be "value" (the ref impl never subtracts 1 from those object values, not even in fieldaddr() or unlink())
- LOAD_VAL: the result of get_longterm() should not be stored in arg3 if it is zero (that is, according to the spec "arg3 <- get_longterm(...)" is executed even if "!arg3" is true; a solution might be to introduce a local variable)

Minor things:
- IF_CWL, IFN_CWL: use "arg2" even though there is only one argument
- STORE_WORD, STORE_BYTE, STORE_VAL, SET_FLAG, RESET_FLAG, UNLINK, IF_MEM_EQ, IFN_MEM_EQ, IF_FLAG, IFN_FLAG: opcode index lists first argument as "VALUE/0", but opcode details have "0/VALUE"
- unbox_int(): "v.tag != integer" should be "v.tag != number" (this is the only occurrence of "integer" as a tag type)
- store_longterm(), push_longterm(): "HEAP.ramsz" should be "HEAD.ramsz"

Suggestions:
- The initial state of the special-purpose registers is never defined (except for INST, though even that is somewhat hidden)
- FIELD_PARENT (=0), FIELD_CHILD (=1), FIELD_SIBLING (=2) are never defined
- It would be useful if pseudo-code invocations of runtime_error() explicitly defined the error_code (as it is probably not meant to be implementation-defined)
- input_get_line() is never defined (according to the Dialog manual this function works in a very specific way, so it is probably better to explicitly define it in the spec instead of leaving it up to the implementation)

lft
Linus Åkesson
Mon 30-Sep-2019 23:00

Thank you very much! I was aware of a few of these issues, because I've started to work on a second implementation (in 6502 assembler) based on the specification document, but I didn't realize that somebody else was having a detailed look at it too. I should make a 0.3 that fixes the errors, without adding any new features.

Also, for what it's worth, the current Dialog compiler never emits AUX_POP_VAL, and I'm thinking about deprecating that instruction. But it ought to remain in the specification until it's time to increment the major version number.