Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Nessphoro wrote:Since the value is over the sign limit it will be negative, so the unsigned int (byte IS extended to dword) for that will have 0xFFFFFF80 stored in it (if 0x80 was pushed), which proves that 0x80!=0xFFFFFF80, which in fact will trash your ISR at the part where you chose what to do with that interrupt (IRQ,Syscall,etc)
This is consistent with what I'm seeing if I use BYTE.
The easiest and simplest thing to do is just use DWORD instead. I will try a different assembler one day, but this will do for now.
I'm not too sure about how stack overwrites are handled (e.g. will imm8 be zero-extended to imm32 before writing it into the stack), intel manuals don't specify that in the PUSH command description.
Mine does.
My Intel Manual vol 2B page 4-296 wrote:If the source operand is an immediate and its size is less than the address size of the stack, a sign-extended value is pushed on the stack.
If a trainstation is where trains stop, what is a workstation ?
it should be correct as long as you only read the lower byte
and we all know the interrupt number is best described as an uint8_t. You just have to fix your function prototype
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Um, no, I pass a pointer to the ESP where the Registers and all that good stuff is stored if I change the interrupt number to unsigned char, it will corrupt all the data.
And why would one do that anyway? You're pretty much wasting 3 bytes, regardless you have no way around it.
And what was push byte meant to solve again? *facepalm*
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
