Re: DRL updated!

X-Comment-To: Michal Tyc

Hi!

23-Окт-2002 12:17 [email protected] (Michal Tyc) wrote to [email protected]:

>> 1. INT instruction not allows an non-constant argument, so you can't call
>> interrupt with variable number else than through manually prepared code
>> (or else you should make 256 times of INT 0, INT 1, etc and then make
>> jump by calculated offset).
MT> Or simulate an INT with PUSHF/CALL (may not work if the V86 monitor needs
MT> to trace this interrupt call).

     Yes, direct call is not the same as INT - see "Solution" for one of the
problem, described in CTMOUSE.TXT. Also, this trick was used in CTMOUSE
itself to workaround the Logitech MouseWare for Windows bad behavior.

>> 2. Selfmodifying code is _not_ incompatible - at least, while you say about
>> "real mode".
MT> Self-modifying code may work perfectly in many situations, even allowing
MT> you to reduce noticeably code size.

     Yes. This is why extensively used in CTMOUSE itself. This (may)
complicate making code DPMS-compatible (i.e. SFM code can't be runned from
extended memory with help of DPMS), as stated by Matthias.

MT> However (as _you_ know for sure, but I feel it should be stressed):
MT> 1. It is not re-entrant. Try to forget about it and find the source
MT>    of all the strange errors that arise ;-)

     Not necessarily: make CLI before modifying INT instruction and all will
work perfect. Should I proof this for you?

MT> 2. It is not ROMmable.

     Yes. :) But BC RTL prepares INT instruction in array on stack. This
solves both problems (reentrancy and ROMmability).

MT> 3. Sometimes it's nice to have a piece of code than can execute in both
MT>    real and 16-bit protected mode. It's hard with self-modifying.

     Anyway, with INT instruction you have _only one_ alternative: table
with 256 INT/RET instruction. It uses 256*4=1K!