 | | Re: signals / legOS internals
|
|
(...) An asynchronous signal models a hardware interrupt. There are times when that is the appropriate interface. There are times when other interfaces are less error prone and are easier to write correctly. Frequently using only synchronous (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Why signals?!? Unix-style asynchronous signals is the last feature I would ever want to implement or use. Brain-dead and very dangerous "feature". As you write; "The problem is that a signal can happen at any time". You shouldn't pass this (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Actually, gcc moves the stack pointer before using any variables, so it is always safe to use stack below the current stack pointer. If you are using a different C compiler or doing assembly tricks, then you are on your own. (...) Traditional (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | RE: signals / legOS internals
|
|
(...) Not to put too fine a point on it, and I hope Kekoa agrees, but the "fluff" is the reason why replacement firmware works in the first place. Without the ROM vectors being dispatched through RAM pointers that are initialized by the ROM and then (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Since it sounds like it might matter to you, I should point out that the interrupt situation on the RCX is a bit more complicated than the H8 manual makes it out to be. Interrupt vectors are in ROM, but the ROM does a dispatch to interrupt (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Yes, that is correct. As for passing parameters to a function, they are simply pushed onto the stack before the function call. Therefore, the H8 stack usually looks something like e.g. this: function param sp+10 function param sp+8 return (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) I may have answered my own question here. Since the SP is adjusted before anything is actually done with the local variables, the rule about it always pointing to the last valid datum is not violated even if local variables are placed after (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) I may have down and up reversed, since different machines grow the stack upward or downward, and I've worked with a few. I do have push and pop clear in my mind, though. So, yeah, down. So, by the "always" rule, nothing will ever be below the (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) When you define a bunch of local variables (more than fit in available registers), where are they? Unless you happen to know the answer, I may have to do some more experimenting. Admittedly, it has been awhile, but the last time I was heavy (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Reading this again, I should mention that pushing things on the stack asynchronously is fine, as long as the stack pointer is always in the right place, which is why it must always always always point to the location I mentioned (and seemingly (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
