I was not able to work on Quartz for some time, but here I am now
@Velko:
Thanks for the tip. Well I can just add "naked" attribute to the function... But I do not. Instead I just put it in an assembly function "_entry".
But sadly that did not fixed the problem. What I noticed is that disabling (e.g. masking) keyboard interrupt and therefore not executing its handler, no stack corruption occur.
I'm not even sure is this really stack corruption or whatever, but I know it's something with keyboard interrupt handler.
Through the fact that it operates correctly in bochsdbg which is not a case with bochs and the fact that each boot gives another random corruption makes me think that this may be something with time, as there is no randomness in computers. (and ironically current time is the key factor of computers we use at homes today random number generation)
...and the fact that I can not debug stack without bochsdbg!
Code:
uint8 _val;
interrupt keyb_irqHandler()
{
_asm pusha
if (inb(KEYBC)&STATUS_READ)
{
_val = inb(KEYBE);
switch (_val)
{
case EXTENDED_SCANCODE1:
prev_ext= k_ext1; break;
case EXTENDED_SCANCODE2:
prev_ext= k_ext2; break;
default:
if (_val & 0x80)//Release
{
_val ^= 0x80;
keyb_down[_val] ^= prev_ext;
keyb_queue[kq_end].ext = prev_ext;
keyb_queue[kq_end++].val = _val;
if (kq_end == kq_max)
{
kq_end ^= kq_end; //Clearing to zero (This way looks familiar, doesn't it?)
}
kq_count++;
if (kq_count == kq_max)
{
//Buffer overflow
}
}
else
{
keyb_down[_val] |= prev_ext;
// TODO : LED update
// Forced
}
prev_ext &= 0;
}
}
intend(1);
_asm
{
popa
iretd
}
}
All of my previous interrupt handlers for Quartz I wrote in assembly because of what I remember that every time I wrote them in C (and before C++) some kind of corruption happened.
"interrupt" at the beginning of function declaration is just a "#define" to "declspec(naked)" (e.g. "naked" function attribute) in order to code not execute between the start of function block and assembly block (and correspondingly to the end of the function).
Although I can write this handler in assembly that's not really a solution... What do I do wrong (or compiler does, doing its optimization) which I can fix?