Hi Adam,
Lemme start with the easiest question first, and work backwards...
Also, when I looked at sample codes online, I usually see int 80h, not int 0x80... what's the difference between these two and why would my teacher want me to use int 0x80?
There's no difference. We could also write it as "int $80", or even "int 128" (decimal). All the same number (bit pattern). Your teacher probably prefers "0x80" because it's compatible with C. The way the boss/teacher prefers is the "right" way.
I also seem to have difficulty differentiating between [num1] and num1. The way I see it is that num1 is the address where the number is stored and [num1] is like dereferencing the address and getting the value stored there. So when I want to manipulate the actual number (like when shifting), I should use the [num1]. Is that about right?
Yup, that's exactly right. There may still be some question of what you need/want, in certain cases, but you understand the difference correctly. Important!
Now we get to the more complicated stuff. In sys_read (from stdin, anyway) edx is the maximum number of characters to read. If you've got space for 4 bytes in the buffer, and 4 in edx, you won't get any more than 4 characters in the buffer, although you might get less. If the pesky user enters more than 4 - including the linefeed - it won't overflow "your" buffer, but the excess will stay in the OS's i/o buffer to screw up your next read, or if you exit the program it'll show up on the command line. I suggested you try "1234ls" - you should see a directory listing. DON"T try "1234rm -fr ." or it'll do real damage! Unix is powerful, and will delete every file on your system if you tell it to. So don't. We really should be flushing that OS buffer after a sys_read...
Since you do have room in the buffer, you could increase edx to 5 and "catch" the linefeed if the user types "1234(enter)" (but "-1234enter" is still going to be too much). If you then made edx 5 in the sys_write, you'd get a newline after the number, which might improve the display. But once we've shifted the characters right or left, the linefeed isn't going to be a linefeed any more, so it isn't going to help that much - you'll just get one more "garbage character".
As I mentioned, sys_read on stdin doesn't return until it gets a linefeed. When it returns, the number of characters/bytes read is in eax. I always say, "including the linefeed", but this isn't always true. If edx were 4, and we saw "1234(enter)", eax would be 4 - which wouldn't include the LF... which would still be in the OS's buffer waiting to cause trouble later. We can use this fact to see if the (OS's) buffer needs flushing. If eax is less than edx, we should be okay. If eax = edx, and the last character in the (our) buffer is a LF (10 decimal, 0xA), we're okay. Otherwise, there's more "junk" which we may want to remove by reading again (and again) until we find the LF. Then we're really done. This may be more "advanced" than you want to get into right now. If eax is less than edx (maximum), you might want to save this somewhere as a guide to how many characters to sys_write later.
sys_write prints however many characters it says in edx, without regard for any zero "terminator", and if there's a (or more) LF(s), it just starts a new line(s)...
As you say, the input is going to be in ascii characters - 31 32 33 34 or maybe 31 32 33 34 0A (all hex). As you can imagine, when we shift this right or left, it isn't going to be ascii characters representing decimal digits any more! If you look at an ascii chart, you'll see that numbers less than 0x20 (32 decimal) are "control characters" not "printable characters". So it isn't a great surprise that "half the number" doesn't display much. I get a "garbage character" there, otherwise my output looks about like your output. That may be "as good as it gets".
As I understand it, the whole point of this assignment is "discuss what needs to be done to get the expected results". There's a clue where he says, "without any conversion...". To do arithmetic on numbers, we need to convert a "string" (I think, in C terms, a "string" has to be zero-terminated, so what we have is just "an array of characters"... but I'll be sloppy and call it a "string") into the number that the characters represent. To display the results, we need to convert the number into a "string" of characters representing the number, and then print that string. I don't know if you're expected to write those conversion routines yourself, or if they will be supplied in some kind of "library". There's some "teacher-supplied code" in the "more than one filename" thread. IMHO it's kinda buggy, but it might give you a general idea what needs to be done...
You mentioned that this assignment is past due. If you can get partial credit for "better late than never", it might be worth trying to clean up the output a little, but I don't think it's ever going to look "good". I'd move on, I think...
Best,
Frank
P.S. Thanks for the input, codeFoil. I'll post anyway, although we say much the same thing.
