Hi!
Let me expand explanation for changes in inthndlr.c:
- inlining "a=b;if(a...)" into `if' ("if ((a=b)..."), at least, in BC
reduces stack reading. Moreover, this also helps for OW (in config.c, for
"pbuffer = HMAalloc()" also disappeared extra stack access). And such
inlining _not always_ makes less readable source.
- inlining expression:
fmemcpy(&getddt(r->DL)->ddt_bpb, xdffp->xdff_f.rebuilddpb.bpbp,
>----------------^^^^^^^^^^^^^ was `pddt'
and removing consequent variables reduces stack usage (at least, in BC).
Again: such inlining _not always_ makes less readable source.
- moving variable definition deeper (and thus reducing its block scope) may
generate better code (especially for BC) and increases readability
(because definition and initialization are nearer). In some case, even
better to add explicit braces around variable usage (especially for C,
where variable may be defined only at block start).
- with lobyte() macro (for example, lobyte(r.callerARG1)), OW sometime
generates slightly better code. This is bonus for more readability.
- all r.FLAGS assigns I move nearer to `break', to make common tails.
- `p' in INT2F/1220 now `_seg' based. For OW this not changes code (because
there `_seg' remains `FAR'), for BC this is identical to explicitly using
word-variable with segment value instead far pointer (which always is
stack variable).
- casting byte/char values back to byte in expressions sometime makes better
code: I already show, how code was significantly reduced for BC. OW in
some cases also may be affected (and this I also show).
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
