 | | Re: LegOS 0.2.5 and LNP
|
| (...) you may see (...) give access (...) the handlers (...) My only (...) depend on. (...) introduce a (...) this point to (...) I think that we can use safely (CONF_TM || defined CONF_HOST) condition. I'm checking the whole patch and I think that (...) (24 years ago, 21-Jan-01, to lugnet.robotics.rcx.legos)
| | | | | Re: LegOS 0.2.5 and LNP
|
| (...) Ok. Checking and testing never hurts :-). (...) It's not for performance, but for correctness. The old code was like this: if(lnp_addressing_ha...ler[port]) { ... lnp_addressing_handl...th-2,src); You first test lnp_integrity_handler and then, (...) (24 years ago, 21-Jan-01, to lugnet.robotics.rcx.legos)
| | | | | Re: LegOS 0.2.5 and LNP
|
| (...) was like this: (...) you reload (...) PC, as you are (...) thing is to read (...) place of (...) optimize it and (...) what you want (...) attribute. Yes, but I'm not sure what could happen if I change those addresses in the middle of the (...) (24 years ago, 22-Jan-01, to lugnet.robotics.rcx.legos)
| | | | | Re: LegOS 0.2.5 and LNP
|
| (...) On the RCX the LNP handlers are called from an interrupt handler, so after the execution of lnp_*_set_handler() you can safely assume that the old handler will not be called any more. On a PC things are different, there is a problem. I didn't (...) (24 years ago, 23-Jan-01, to lugnet.robotics.rcx.legos)
| | | | | Re: LegOS 0.2.5 and LNP
|
| (...) after (...) old (...) That's true. I've noticed it. I was speaking of PC implementation. (...) semaphore (...) in a (...) instruction (...) wait (...) of the (...) shouldn't (...) Ok, perfect. I vote for the semaphore implementation. I also (...) (24 years ago, 24-Jan-01, to lugnet.robotics.rcx.legos)
| |
