mechaniputer / libredssp

A GPL Licensed DSSP Interpreter

libreDSSP

A GPLv3 Licensed DSSP Interpreter

libreDSSP (libre Dialog System for Structured Programming) is a free software interpreter for the DSSP language. This language originated in the Soviet Union and was designed for the Setun ternary computer. It is very similar to Forth but has more compact syntax along with arguably more consistent rules regarding the behavior of stack operations and the evaluation of variables and addresses. This implementation is not yet complete, but it is complete enough to experiment with. Work has resumed after a long delay but it will continue to be sporadic due to my busy schedule.

To our knowledge this is the only maintained DSSP implementation, and the first to be free software. It is lacking in many areas but progress is being made to add features and make it faster.

The ultimate goal of this project is not to merely replicate DSSP as it once existed, but to improve on it where possible without betraying the philosophy of the language.

Getting started

Run 'make' to build it. You may wish to use the included tutorial by running './dssp examples/TUTOR.DSP'. Vim source highlighting files are included in vim/.

Contributing

Pull requests with good style that solve actual problems are appreciated. When in doubt check the issues tab and feel free to comment for clarification or advice. If you find a way to crash the interpreter, make an issue. You may want to search for documents about prior implementations of DSSP. Most of them are in Russian which makes it difficult to get a full understanding of the language, and there have also been several dialects of DSSP. This project does not aim to precisely match any particular dialect but aims to have a high degree of compatibility with most of them.

The libreDSSP tutor (TUTOR.DSP) does not yet cover all of the implemented language features. Pull requests to add or improve training steps are appreciated.

One of our greatest challenges is finding unambiguous information about this obscure language. If you have anything that might help with that, let us know.

Also let us know if you are interested in setting up other resources such as an irc channel or a website. I don't currently have the time to manage anything like that.

What works

* Basic math operations (+,*,-,/)
* 1+, 2+, 3+, 4+, 1-, 2-, 3-, 4-
* =, <, >
* NEG, ABS
* BYE, ..(show stack), .(show top of stack)
* IF+, IF0, IF-
* BR+, BR0, BR-, BRS, BR
* DO
* D (drop), C (copy), DS (drop entire stack)
* DEEP (push height of stack)
* ET, E2, E3, E4
* CT, C2, C3, C4
* Function declarations
* GROW, USE, SHUT, ?$
* Integer variables
* TIN, TON
* ."hello" printing, SP, CR
* [comments]
* GNU readline support
* Read from file at start
* B10 (as a placeholder since we currently only support base 10 I/O)

What doesn't work yet

* SAVE, LOAD
* ONLY, CANCEL, FORGET, CLEAR
* Variable addresses using '
* Arrays, fixed variables, etc
* RP
* SGN, NOT
* EX, EX-, EX0, EX+, EXT
* SORT, SPIN, MAX, MIN
* T0, T1
* TRB, TOB, BASE@
* TIB, TIS
* B2, B8, B16
* SHL, SHR, other bitwise operations
* Everything unaccounted for in this README

Possible future goals

* Full documentation
* Floating point math
* DSSP Compiler
* Multithreading support

libredssp's Issues

Variables and types

It looks as though variables are supposed to be declared like 'VAR foo' before being assigned a value. Currently the 'VAR' keyword is not implemented and variables can be assigned without first declaring them like: '7 ! foo'

See this document: http://brokestream.com/daf.txt

Declaring a variable with VAR should result in that variable being named, allocated and initialized to zero. Implicitly declaring a variable through the assignment operator should print a warning that this will be deprecated in a future release.

Types should also be supported like this:
WORD VAR foo
BYTE VAR foo

WORD should be the default type, corresponding to the size of the machine word.

Leaks memory like crazy

Need to free stack elements when they are no longer needed in corewords.c. This will be a lot of unique work for each core word.

Multiline comments and function definitions not supported

Multiline comments and function definitions not supported. To fix this, defer evaluating command stack until after the necessary terminating character is found in a future line. The prompt style should change to a '?' as well.

Cannot define function inside another function

I see no reason why it should be illegal to define one function inside another function definition. Sure it's kind of an evil thing to do, but it should be technically allowable.

The current behavior allows it at the parser level but when evaluating the command stack, the inner semicolon terminates the outer function definition, and then the next semicolon is treated as a stray character.

Maybe handling this case will be easier after an inevitable complete REPL rewrite.

Impossible to cleanly exit interpreter during multi line statement

When in the middle of a multi line comment or function definition, a ? prompt is displayed and evaluation of the command stack is deferred. This makes it impossible to exit the interpreter. CTRL+D should exit the interpreter in this situation, but typing BYE should not because it is acceptable to declare a multi line function that uses that word.

Vim highlighting doesn't deal with negative numbers

This line has some problems due to the negative numbers:
: step6b -4 double BR -8 step6good ELSE step6bad ;

DO word can segfault

The current implementation of DO (internally named doloop) at line 294 of corewords.c has serious bugs.

The simplest way to observe the problem is to run:
2 DO .

A similar problem occurs when running the following command twice in a row:
3 DO .

The first execution triggers an error about an empty string being present in the command stack and aborts execution. The second execution triggers a segmentation fault.

The problems associated with this command derive from the nature of what it must do. In order to repeat a command, it places multiple copies of that command onto the command stack. Because the stack is implemented as an array, a realloc can cause references to become invalid. Additionally, a push can overwrite an element which has been popped. I'm not sure if either of those cases are relevant to the current bug.

Parser is horrible

The piece of code that takes a line of input (from either a file or the interactive prompt) and divides it into commands is especially horrible and error-prone. The command stack itself should probably be rewritten as a queue so that the parser doesn't need to fill a linked list before adding anything to the stack (in reverse order). It could instead just put stuff right into the back of the queue.

This calls for a fundamental redesign of the way commands are processed prior to being evaluated. This is the worst part of the code right now and also the most annoying to rewrite. It greatly affects the efficiency and safety of the interpreter so it is a high priority.

Printing without terminating quote should print an error and not print anything else

For example if I do ."hello
(note the missing endquote)
then it currently prints "hell"

Word declarations, comments limited to 160 chars

See TODO items in stack.c

Vim syntax highlighting buggy

The provided files for syntax highlighting have undesirable behavior in several situations:

1. When there are several comments on a line with code between them
2. . and .. are not highlighted
3. Function declarations are not fully highlighted if they contain non-alphanumeric characters
4. It would be nice to also highlight the ';' at the end of a function declaration

Need escape character when printing

I don't know if earlier implementations used any particular escape character but at present it is not possible to use the ."hello" printing syntax to print a double quote. Should research whether any particular character has historically been used for this in DSSP. Otherwise just pick a sane one.

Spacing in word declarations

Original sources seem to indicate that a space preceding the ';' symbol in a function/word declaration is not necessary. Currently libreDSSP requires a space there. This requirement should be relaxed.

For example:
: one 1 ;
could also be written as
: one 1;

Tabs not handled

Tabs should be treated like spaces