search

catseye / Funge-98

MIRROR of https://codeberg.org/catseye/Funge-98 : The Funge-98 specification in all its gory
https://catseye.tc/node/Funge-98
32 stars 2 forks source link

Befunge-93 cells were not unsigned #2

Closed j4james closed 6 years ago

j4james commented 8 years ago

In comparing the Funge-98 virtual machine to Befunge-93, the specification says:

Befunge-93 defines signed 32-bit stack cells and unsigned 8-bit Funge-Space cells.

However, that seems like a fairly dubious claim when the Befunge-93 documentation said nothing of the sort.

A Befunge-93 program is treated as an 80x25 torus ... of ASCII text.

Each command in Befunge-93 is a single character, as is the largest data unit that can be specified in the program source.

There's no mention of whether the data units are signed or unsigned.

Looking at the source of the reference implementation, the code page is defined as a char array, and in ANSI C it's left up to the compiler implementation to decide whether a char is signed or unsigned. So at best, then, you could maybe say the signed state of the cell type was undefined.

However the DOS version of the reference implementation was built with Borland C++, and according to their documentation (see page 158), they interpret the char type as signed by default. You can confirm that to some extent by testing some of the older reference binaries that are still available online:

So what is the source of the claim that the cell type was unsigned? Was the original Amiga version of the interpeter built with a compiler that used an unsigned char?

Certainly by the time the Funge-97 and Funge-98 specs were being developed, it seemed generally accepted that playfield cells were signed. Some quotes from the Befunge mailing list:

the stack has signed 32-bit integers, and the memory matrix has signed bytes.

Something to note is that in bef-93 the grid data type is signed...

A better way to say this would be that -93 used a single signed byte for each memory cell in the program space, and that -97 uses a 4-byte signed doubleword.

The last quote was suggested copy for the '97 version of the spec, and that even seemed to be something you agreed with at the time (your reply was: "OK, it'll say it something like that.").

Furthermore, if you look at some of the early examples of Befunge programs, some of them just wouldn't work if the cell type was unsigned.

Admittedly the latter was written several years after the Funge-98 spec was finalised, but it's got to be one of the classics of Befunge. If an interpreter can't run Befunge Chess, it's just not a real Befunge interpreter as far as I'm concerned.

Anyway, this obviously makes no difference to the Funge-98 language itself, but if the spec is going to include commentary on Befunge-93 as well, it would be good to get those facts straight.

cpressey commented 8 years ago

However, that seems like a fairly dubious claim ...

Indeed. It's a fairly dubious spec.

... some of them just wouldn't work if the cell type was unsigned.

Well, that's a fairly strong claim! What behaviour do you see when you run them on an interpreter with an unsigned cell type, and on what basis do you say that that observed behaviour violates those programs' specs?

clears throat

Well anyway.

Given the dozen-or-so questionable statements this document makes about the language it claims to define, I don't think it's worth worrying about any claims it may or may not have made in the past 18 years about any other languages it may or may not also make mention of.

j4james commented 8 years ago

What behaviour do you see when you run them on an interpreter with an unsigned cell type, and on what basis do you say that that observed behaviour violates those programs' specs?

When executed on a signed interpreter, Lahey's Mandelbrot fairly closely resembles the ASCII rendering on Wikipedia, although further zoomed out. On an unsigned interpreter, it looks like a small pile of poo. Given that he described the program as 'a text version of the mandelbrot set', I think it's reasonable to assume that the former interpretation was more likely the intended one.

As for the chess implementation, you're just going to have to take my word for it that in a typical game of chess, when the white player makes his opening move, it's not usual for his opponent to immediately collapse on the board and die. That's basically what happens when you try to run that chess program on an unsigned interpreter.

Given the dozen-or-so questionable statements this document makes about the language it claims to define, I don't think it's worth worrying about any claims it may or may not have made in the past 18 years about any other languages it may or may not also make mention of.

Not expecting you to fix anything if you don't want to. Just wanted to provide some documentation of the issue for others that might stumble across this page while looking for more information on Befunge.

cpressey commented 6 years ago

Not expecting you to fix anything if you don't want to. Just wanted to provide some documentation of the issue for others that might stumble across this page while looking for more information on Befunge.

I suppose adding an ERRATA document to this repo, to include the information in this issue and in #5 in a non-Github-specific way, would not be unmeet.

cpressey commented 6 years ago

Also, reading this again, the original bef.c was originally compiled with DICE C under AmigaDOS 1.3. While that compiler's behaviour can't really be considered normative here (the mailing list quotes would be a much stronger de facto description of the language behaviour, I think), it would indeed have produced the bef executable that the first few Befunge programmers used to write the first few example Befunge programs, so finding out what signedness it used for char would be of historical interest.

cpressey commented 6 years ago

This error has been listed in the ERRATA document, which has now been released. Thank you for your report. Closing this issue.

(If I investigate the signedness of chars in DICE C it will probably be something I do as part of Befunge-93 archaeology. But if I find out anything I'll try to remember to update this issue with it too.)

j4james commented 6 years ago

Thanks for following up on this issue. Regarding DICE C, I did a bit of digging last night, and it turns out that the source code for the compiler has been made public, so you can download it from here:

http://legacy.obviously.com/dice/

And if you have a look at the limits.h file in the include directory, you'll find the following defines:

#define CHAR_MAX    SCHAR_MAX
#define CHAR_MIN    SCHAR_MIN

#define SCHAR_MAX   127
#define SCHAR_MIN   -128

This suggests to me that the char type was almost certainly signed, but I couldn't actually get it to compile anything to test for certain. It seems to require Amiga libs that aren't included, but maybe if you've got an old Amiga knocking around somewhere you might get further with it than me.

Also note that the copyright date on that file was 1992, so it seems likely this would have been close to the version you were using at the time that Befunge-93 was originally developed.