# possible bug part 4

6 messages
Open this post in threaded view
|

## possible bug part 4

 This post was updated on . It might not just be a possible but an actual bug. I did this in my test.asm because breaking things is a specialty of mine. @1 //set register A to 1 @2 //set register A to 2 @R01 //this registers as a symbolic instruction like @address M = M - 1 //sets the value of the memory pointed at by R01 to -1 M = M - 1 //sets the value of the memory pointed at by R01 to -2 in the assembler it sets @R01 to the address 10000 in binary, I don't know if you'll get different. but what happens if I do a bunch of things and then set D to some value, let us assume 2012, then have to store it in memory 16 (10000 in binary!) because I've run out of memory registers for whatever it is I was doing. @16 M = D I've just overwritten -2 with 2012 if I do a jump command to @R01 @R01 D;JGT //assume we will jump at this point. then do some calculation like D = M + D then instead of getting some value decreased by 2, it will instead increase by 2012. Here below are 2 screenshots of this in action If you guys get this please make a fix because this could be a bug that might if not already has broken some hack code.
Open this post in threaded view
|

## Re: possible bug part 4

 Administrator Chamkey wrote It might not just be a possible but an actual bug. I did this in my test.asm because breaking things is a specialty of mine. @1 //set register A to 1 @2 //set register A to 2 @R01 //this registers as a symbolic instruction like @address M = M - 1 //sets the value of the memory pointed at by R01 to -1 M = M - 1 //sets the value of the memory pointed at by R01 to -2 On what basis to you claim that your first M=M-1 instruction sets the memory pointed to by R01 to -1. This assumes that it was previously equal to zero and I don't see anything that is making that happen. in the assembler it sets @R01 to the address 10000 in binary, I don't know if you'll get different. This is exactly what it should be set to unless you have a previously used variable. The assembler is supposed to assign variables to RAM addresses beginning with address 16 (which is 10000 in binary). but what happens if I do a bunch of things and then set D to some value, let us assume 2012, then have to store it in memory 16 (10000 in binary!) because I've run out of memory registers for whatever it is I was doing. @16 M = D I've just overwritten -2 with 2012 Well, what would you expect or want to have happen? If you are going to explicitly store something in RAM[16], it is YOUR responsibility to ensure that nothing else is using that memory location. Since you KNOW that the assembler IS going to assign the variables it finds to memory locations starting at 16, then this means that you can't have ANY variables in your program. if I do a jump command to @R01 @R01 D;JGT //assume we will jump at this point. Why would you want to jump to ROM address 16 just because the variable R01 is associated with RAM address 16? That makes no sense whatsoever. then do some calculation like D = M + D then instead of getting some value decreased by 2, it will instead increase by 2012. Why would you expect it to do anything else? Here below are 2 screenshots of this in action If you guys get this please make a fix because this could be a bug that might if not already has broken some hack code. What bug???? It is doing EXACTLY what the language specification requires. It is YOUR responsibility to write code that behaves correctly in light of what the language specification requires.
Open this post in threaded view
|

## Re: possible bug part 4

 In reply to this post by Chamkey Chamkey wrote ... @R01 //this registers as a symbolic instruction like @address in the assembler it sets @R01 to the address 10000 in binary, I don't know if you'll get different. @ABC can have a few meanings: - it could be predefined, like @THIS or @R1 - it could be a label defined in your program with (ABC) - if it's none of the above, then it is assumed as a new "variable". The assembler allocates these from address 16. The @R01 in your program is from this last category. Chamkey wrote but what happens if I do a bunch of things and then set D to some value, let us assume 2012, then have to store it in memory 16 (10000 in binary!) because I've run out of memory registers for whatever it is I was doing. @16 M = D The memory registers 0 - 15 have mnemonic names: R0 - R15 (plus additional names, like THIS, THAT, LCL, etc, which will make more sense in later chapters). Memory addresses from 16-255 (if I remember correctly) are used for symbols of the third kind. In the HACK architecture the memory up 16383 is just RAM. It doesn't have any special meaning. But because the CPU has just 2 internal registers, the authors named the initial 16 addresses as additional registers. (They are still registers in the RAM and not internally in the CPU.) This does not mean that your program cannot use the rest of the memory. It just means that you need to be aware of the architecture and of how the assembler works. Chamkey wrote if I do a jump command to @R01 @R01 D;JGT //assume we will jump at this point. First of all, I don't see this jump command in the screenshot below. Second, in HACK there is ROM where the program is stored and RAM where data is stored. They both have addresses starting from 0. The difference is, that the CPU will read the instructions only from ROM and will read data only from RAM. When you write @R01 this will be treated as label from the third kind and will get an address 16 (assuming it's the first such label in your program). So @R01 is compiled as @16. The next jump will jump to address 16 in ROM, which from the screenshot is empty. That is, the ROM there is undefined (probably 0?). You can write things like: ```@R1 0;JMP // Jump to the address 1 (second instruction in your program) ```or ```@R01 0;JMP // Jump to address 16, assuming R01 is from above ```or ```@123 0;JMP ```but all these are bad practice, because they will confuse you, the programmer and may introduce subtle and hard to find bugs. The first 2 forms should be used to access RAM addresses, while the @123 form should be used to store immediate values. If you want to jump to some address in your program, you should define it with a label like this: ```... (LOOP) ... @LOOP 0;JMP ```or ```... @LABEL D;JGT ... (LABEL) ... ```Again, technically there's nothing stopping you from doing something like: ```@LABEL M=D ```but it's a bad practice. Chamkey wrote It might not just be a possible but an actual bug. ... If you guys get this please make a fix because this could be a bug that might if not already has broken some hack code. A piece of advice: always start by assuming the bug is in your code. Next, check your colleague's code, then library code, compiler/interpreter, OS and last, the hardware. This is the order from the least tested to the most tested.
Open this post in threaded view
|

## Re: possible bug part 4

 In reply to this post by Chamkey Sorry for replying so late. Was at a friend's house for the past week. I've learned my lesson, please don't hurt me. Lol. I realized that I was doing the same thing in my assembler. I also assign values to registers starting from register 16 because 0-15 are used by specific keywords which also means that register 16384 and register 24576 are being used. I was going to assign the new labels to random memory registers but then I realized I had no control over which register it would overwrite and that could lead to a huge mess down the line so doing it sequentially starting at 16 is favourable. I'm sorry I jumped to conclusions regarding the given assembler. Looks like I have much more to learn. Thank you for pointing out my ineptitude.