Console input semantics

[JoJoDeveloping]

Hello there,

First of all: Console input currently is a bit broken. If you output a few chars (like the $PS1 / user@machine ~ $ prefix usually output by sh) and then try to read console input, and the user just presses enter, the chars already output are again read. You can also edit it using backspace, once you type a few chars.

A solution (which I have implemented along with some of the things suggested below, and can PR if wanted) would be to keep track of the "last output char", and only allow editing until that point in the line, while removing things before that when sending the line to the process.

This leads to a general question: What is the motivation behind the current console semantics? It seems unnecessarily convoluted. Specifically, why don't you make it so that every line you enter into the terminal is send to the program, including terminating newline?

"Enabling" the terminal (ecall 0x130) could then be removed, too -- what was the point of it? All it does is potentially drop input when you invoke it too often, since it resets the input buffer? Simply buffering all input for the user to consume seems like the more sensible option, especially since it also better approximates normal console input (i.e. reading from stdin), as well as the semantics of MARS.

I'm aware that the suggested changes break backwards compatibility. If that is an issue, they could be delegated to new syscalls (perhaps those orignally intended for console input, i.e. 5-8 (see https://www.doc.ic.ac.uk/lab/secondyear/spim/node8.html))?

I'm happy to learn about what motivated the current design, in case there's something I missed.

Thanks!

[wallento]

Thank you very much. The input was more in a mock-up state and your PR would be highly appreciated!

[wallento]

No need for backward compatibility, I am not aware of active users relying on this to behave as our mockup.

[m1n1]

Yes the whole terminal is as @wallento said very much in a mock-up state.

As for handling user input I actually have some ideas outlined #78 .

As for console semantics the ecall 0x130 was implemented as a simple way to recreate console.readline. Eventually also the whole communication between the terminal and the simulator should be overhauled. Ideally we would like to use memory mapped I/O for terminal communication. (Maybe something like this). For this to work first Interrupts have to be implemented, which we are working on.

All this said, for now we don't really have a concrete timetable and it will propably need some time before all this will be implemented.

Depending on your use case console communication could also be implemented in another way and any PR would be welcome.

[JoJoDeveloping]

We were just hoping to re-implement the old MARS/SPIM syscalls to read integers/chars/strings, since these are the easiest to use and make porting legacy software possible. I agree that MMIO is likely preferred as you aim to move the simulator "closed to hardware", perhaps there's a way to make this conditional on the run config.

This is likely to require some changes to the structure, notably making everything suspend funs so that you can wait for console input to happen.

For now, I'm also working on getting the web frontend to work again, since that broke when you switched to commonjs. You don't just happen to know how to fix that? (I feel like it will require making the frontend use node.js properly, so you can properly require('venus').)

[m1n1]

There is currently no way to get the web frontend working in vscode in an easy manner. As you mentioned vscode runs in a nodejs context.

Theoretically you could port the whole frontend to a webview. But because our code runs in the vscode extension/node context you would need to implement all communication and state manually. For example our memory view is taken from the original web frontend and modified this way. Doing so is time intensive though.

Can you elaborate why you would want to use the web frontend? If you really need the web frontend why don't just use the original repo we forked from their online site

[JoJoDeveloping]

We don't want the web frontend in vscode, but rather in the browser (as it used to be), sharing the same backend. The current way the backend is compiled breaks things, but switching to not using commonjs also breaks some dependencies.