Extending BIT



  • I'm writing a compiler for Cool 2015 that outputs BIT. So far, I've encountered two problems and would like to see how other TDWTFers would solve them:

    1. There is no way to determine if a READ instruction hits EOF. Currently, the interpreter exits immediately on any IO error, including EOF, but the language spec doesn't say anything about what to do in this situation. I was thinking of adding something to the grammar like "READ [optional line number for errors]".

    2. There is no computed GOTO in BIT. That means I can't do x86's RET instruction or MIPS's jr $ra instruction. I was thinking of having my compiler generate a huge table of method starts and instructions directly after method calls and then doing a bitwise binary search to see which GOTO instruction I should hit.



  • Be careful about that, modifying your BIT can be dangerous... :smile:


  • Discourse touched me in a no-no place

    @ben_lubar said:

    that outputs BIT

    Dear $DEITY why?


  • sockdevs

    @antiquarian said:

    Dear $DEITY why?

    because benlobjasticlyfromulent was not enough punishment to place upon us.



  • lojban isn't a very good language to compile to because it's higher level than Cool. BIT is lower level than x86 assembly.



  • @ben_lubar said:

    lojban isn't a very good language

    Correct.



  • @ben_lubar said:

    BIT is lower level than x86 assembly.

    Just because you swear more while working with it, it doesn't mean it's lower level.


  • sockdevs

    @Gaska said:

    Just because you swear more while working with it, it doesn't mean it's lower level.

    perhaps he means it's a lower circle of hell?



  • Lower in which direction?



  • I'm assuming @accalia isn't referring to the number.



  • You're also assuming I was assuming @accalia was referring to the number, which I clearly* did not.

    * - actual clarity may vary depending on your mind reading skills



  • Well, there are only two ways to define a "lower" circle of hell:

    • A circle of hell with a lower number that is physically higher
    • A circle of hell with a higher number that is physically lower


  • There are more:

    • A circle of hell with a lower number that is also physically lower;
    • A circle of hell with a higher number that is also physically higher and @accalia is wrong about it being lower.

    And all these don't cover the most common depiction of Dante's circles of hell, which are all on the same surface, arranged inside-out in descending order, where the only definition of "lower" that makes sense is "more to the outside", ie. "less harsh".



  • If hell is located inside a planet, then down is the direction of gravity, which would either be towards the center of the circle or that's a really fucked up angle they built the floor at.





  • @Gaska said:

    most common depiction

    I'unno, seems quite vertical to me.



  • Facts are barrier to civilized discourse.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    There is no computed GOTO in BIT. That means I can't do x86's RET instruction or MIPS's jr $ra instruction. I was thinking of having my compiler generate a huge table of method starts and instructions directly after method calls and then doing a bitwise binary search to see which GOTO instruction I should hit.

    IIRC Tierra does something vaguely like that--in their case they wanted a construct not used in any real-world assembly language in case a program escaped the VM (although that may have been a joke).


  • Discourse touched me in a no-no place

    @ben_lubar said:

    There is no way to determine if a READ instruction hits EOF. Currently, the interpreter exits immediately on any IO error, including EOF, but the language spec doesn't say anything about what to do in this situation. I was thinking of adding something to the grammar like "READ [optional line number for errors]".

    That depends on the current range of results of READ. If they're a byte, let the result be an integer with correct results ranging 0–255 and error conditions (including EOF) signal with -1.



    • READ - this reads a bit from the standard input and sets the jump register equal to that bit. Again note that only a single bit is read per READ statement, and a bit sequence that may represent an ASCII character needs to be read in one bit at a time.

  • Discourse touched me in a no-no place

    Well, whoever defined it to work that way is an idiot that's never written real I/O code in their life; failures really are a fact of life. You must handle three cases even when reading single bit: 0, 1 and error (a.k.a. FILE_NOT_FOUND ;)). If this messes up their little model, that's too bad.



  • Keep in mind this is the guy who invented LegPEG 3.


  • Discourse touched me in a no-no place

    From what I've seen of BIT, programming anything in it will be slightly more painful than using sandpaper on your genitals, so why should I/O be any different? :trolleybus:



  • You must have seen the other thing too to make such comparison.



  • Just add an eof instruction that you can call after each read to check if there is data remaining. As for gotos: I don't recommend it. You don't want to make your code an unreadable mess do you?



  • So, add a CHECKNEXTREAD instruction. It sets the jump register equal to 1 if the next read would return an error, and to 0 if it would succeed (or vice versa).

    That whole thing is still going to be a pain to use, but at least you can handle IO errors (now whether or not end-of-input should be considered an error like any other is a topic for another time).


  • Discourse touched me in a no-no place

    @cvi said:

    That whole thing is still going to be a pain to use

    I get the impression that that's the whole point of BIT.



  • @Gaska said:

    You must have seenexperienced the other thing too to make such comparison.

    FTFY


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.