Question about Brainf**ck Interpreter/Compiler

Sorry, I forgot to login before posting. The post above is from me.

Sure; it's http://www.brainfuck.ca/BF2C.c16; it converts .bf to .c, then it's compiled with gcc..

But I don't know how it handles EOF, sorry

Hello,

On a trial-and-error basis I established that BF reads in -1 at EOF.

For instance,

,+[-.,+]

acts as en echo till EOF.

This is pretty natural, considering that BF is nothing more than the mapping table:

becomes ++p;
< becomes --p;
+ becomes ++*p;
- becomes --*p;
. becomes putchar(*p);
, becomes *p = getchar();
[ becomes while (*p) {
] becomes }

Thanks for your quick answer.
I tried the converter, and I realised my mistake. The reason why I got TLE was that I assumed that the buffer is a char buffer, but it is a int buffer. So when I tried to get something negative to zero, I assumed I just can substract until it goes back to positive and then to 0.
I changed it, and now I don't get TLE. Now I have to figure out why I got WA (I am trying some random inputs against a C-program now).

Hi. This is my first post at this forum.
I've read somewhere that when you read:
if EOF then byte that you read =0
if not EOF then byte = Ord(char)
The best article that I found on net: home.planet.nl/~faase009/Ha_BF.html3

Brainfuck is not defined in terms of a mapping table between brainfuck and C, though it is frequently explained in terms of such a table.
The original compiler and Müller's last interpreter leave the cell's value unchanged on EOF. Some other implementations store 0 or -1 in the cell.
In brainfuck, a newline is 10, whereas in C it may or may not be.
It's worth noting that programs compiled with bf2c will output a spurious newline at the end.
-Daniel Cristofani.

Well, I didn't exactly write it was defined as such, but that is probably what I meant . Thanks for setting me straight.

Does this mean that, when reading input, the character pair CR LF should always be read with a single , command as the single character 10? I believe we always use text files, so BF2C should work OK, but nevertheless it would be good to know.

An ideal implementation would let the user set a flag to indicate the nature of the input:
-In binary-input mode, the bytes are read unaltered. (The most obvious example is the CSS decryption program.)
-In text-input mode (the default), any newline format the program is likely to encounter will be read with a single , command as the single character 10. On a Windows machine this certainly includes translating the CR-LF pair as you describe. On a Linux box that doesn't have a lot of DOS-format text files lying around, this shouldn't be necessary, and indeed the distinction between the two modes collapses.
Good luck;
-Daniel.

I get TLE with the same reason.
But I didn't think it is my mistake.
I think we should change "int x[32768];" into "unsigned char x[32768];"
in the convert c problem.
If I change my code to fix the buffer in int my code will be very ugly...

I changed my code and get AC.
But I still hope the admin can do the change.
Because this is not explained. And I see many people get TLE and didn't know why.

Of course it can be changed But why would you like the char to be unsigned (don't negative integers come in handy sometimes?)... And perhaps the range of the data type should be made a little wider. We would have to test how much is required for backward compatability with earlier submissions, but I guess even some custom value like [-2^12, 2^12) is perfectly acceptable from everyone's point of view..

The reason is somewhat different . The trouble is the name of the compiler 'bf2c + gcc': some people are confused and submit C code as BF. Quite naturally a construct like: int a, b[10]; becomes an infinite loop in BF .

Altering / rewriting the compiler would be a good pretext to change the displayed name.

And I also get TLE on the CRYPTO3 problem... while on every single possible entry (1000 possibilities) I get the right answer with my compiler or Frans Faase online version .

The www.brainfuck.ca link (mentioned in another post) seems to be broken. Where can I get the compiler used on spoj to understand where the problem may lay ?

Thanx a lot !
--
G18

I just put it on http://spoj.sphere.pl/bf2c.c5 Hope it helps.
It used to be on www.brainfuck.ca2 you mentioned; the only change we made is "return 0;" at end of the generated program to prevent NZEC.

No, I think this (4byte range instead of 1 byte range) is the main reason for many TLEs. At least for mine -- like AdrianKuegel, I thought I could do [-] to make any integer zero (because of overflow), but for negative integers, it times out. I changed it and got it working in 0.00 seconds. So you can make it char or short int, I am sure no one uses integers very big (after all, using very huge integers is likely to time out anyway).
And also, unsigned or signed makes no difference, I think -- all BF programs will work the same either way, probably. Whether the C program declares them as signed or unsigned, you can still decrement below 0, and increment it back to get the same integer, so it doesn't matter.

Thanks,
Shreevatsa

Yes; my SBSTR1 just timed out because of this very reason. I changed the definition from "int" to "char" in bf2c.c and it ran significantly faster. (~30m versus .05s) I also made another minor improvement whereby bf2c will collapse repeated additions, subtractions, and pointer movements like:

x[xc]++; x[xc]++; x[xc]++; x[xc]++;

to

x[xc] += 4;

It is unclear to me whether or not gcc already does this. In any case it certainly shrinks the output file a bunch.

I agree with that. I had had some trouble until I found the problem was this "long loop" of making memory cell equal to zero. I suggest the program bf2c to be modified to a char array, because int is painful in a increment/decrement language!

I had the exact same problem with TLE. It was also due to the use of [-] to clear memory locations that contain a negative value. That takes ages for a 32bit value.

The bf2c compiler is broken afaik, since the brainfuck language specifies that each memory cell holds one byte (not a 32 bit int). My (custom) brainfuck interpreter doesn't have that problem, so it took a while before I realized that the TLE's were due to bf2c.

It seems this has been an issue to many for several years now - which makes me wonder why it hasn't been fixed yet.

I agree with infinity. Such a large upper bound is useless. I can't even [-] without timing out. Can we just use shorts?

I have run into the same problem with [-] and TLE.

Has someone found a solution for this?