Hi!
30-Апр-2004 23:32 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> #define lonibble(v) (0x0f & (v))
>> #define hinibble(v) (0xf0 & (v))
BO> hinibble is ambiguous. Suppose I use
BO> hinibble(0x1234)
BO> with your macro I get 3 and not 1.
This depends how you _wish_ understand this. I understand this as
hinibble gets hinible in byte, hibyte gets hibyte in word, etc. So, no
ambiguites, also as for AL/AH/AX/EAX.
BO> same problem here. hibyte(0x12345678) = 0x56 ????
Yes. For higher bytes apply hiword: lobyte(hiword(v)) and
hibyte(hiword(v)). Very convenient and readable.
BTW, you may _name_ this as "nibble0()", "nibble1()", "byte0()",
"byte1()", etc, but this is question of taste.
>> These macroses allow to make more readable
BO> I don't agree.
You may dislike "hibyte" name. Ok, hibyte is no such important as
lobyte, inline it: lobyte(v)>>8. But again, _expression_ is (usually) less
readable, than good name for it. Also, for some compilers you may have more
efficient ways to get hibyte(), than >>, like for MK_FP in BC used _seg
modifier.
BTW, about _seg. _You_ yourself offer use _seg for BC. I implement this
("const psp _seg *p" instead "psp FAR *p" or "seg_t psp_seg") and found that
this is identical to "seg_t psp_seg":
______________O\_/_________________________________\_/O______________
@@ -1945,28 +1925,24 @@ VOID ASMCFUNC int2F_12_handler(struct in
case 0x20: /* get job file table entry */
- {
- psp FAR *p = MK_FP(cu_psp, 0);
- unsigned char FAR *idx;
-
+ {
+ const psp _seg *p = FP_SEG_PTR (const psp, cu_psp);
[...]
- idx = &p->ps_filetab[r.BX];
+ r.ES = FP_SEG (p->ps_filetab);
+ r.DI = FP_OFF (p->ps_filetab + r.BX);
r.FLAGS &= ~FLG_CARRY;
- r.ES = FP_SEG(idx);
- r.DI = FP_OFF(idx);
- }
- break;
+ break;
+ }
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
+#if __TURBOC__ > 0x202
+# define FP_PTR(type,seg,ofs) ((type FAR*) MK_FP (seg, ofs))
+# define FP_SEG_PTR(type,seg) ((type _seg*) (seg))
+#else
+# define _seg FAR
+# define FP_PTR(type,seg,ofs) ((type FAR*) MK_FP (seg, ofs))
+# define FP_SEG_PTR(type,seg) ((type FAR*) MK_FP (seg, 0))
+#endif
_____________________________________________________________________
O/~\ /~\O
But you ignore this (your offer). Why? Also, you again don't answer why you
don't fix (yet) is_suspect (although you already agreed that this was right
way)?
>> more portable
BO> Not at all. v & 0xff is the most portable construct.
Ok, rephrase: "at least, same portable". Also, for some compilers you
may tune code (in one place) and remain portable.
>> and, in some cases, more effective code.
BO> When?
I already quote you listing, how BC generates worser code for "ch -=
'a'-'A'" without casting ("(UBYTE)('a'-'A')"). Also, don't remember if I
quote you listing, but (my) lobyte generates for BC better code (because no
extra instructions like "and dl,255").
BO> Do you mean that Turbo C puts in stupid code such as
BO> and ax, 65535?
BO> well that's the compiler's fault, not ours.
Of course. But why not use more readable code, if it _also_ generates
_not worser_ code (and better for some compilers)? Also, "a = 0x0f & b" is
shorter, than "a = b & 0x0f".
>> put_unsigned((unsigned)(clussec & 0xffffu), 16, 4);
>> You may wrote:
>> put_unsigned(loword (clussec), 16, 4);
BO> I think it should just be:
BO> put_unsigned(clussec & 0xffffu, 16, 4);
BO> as Turbo C is too stupid to realize that these two values do not lose any
BO> significant digits I'm forced to disable that warning using -w-sig...
It not "stupid", it just not presents too many extensions over
standard. Same I (and you) may say about OW. I already report this for OW
team:
______________O\_/_________________________________\_/O______________
Language and libraries:
- (with -wx option) WPP diagnoses ("W716: integral value may be truncated")
"bytevar & 0x18" expression, which passed to byte parameter.
_____________________________________________________________________
O/~\ /~\O
>> ______________O\_/_________________________________\_/O______________
>> #ifndef I86 /* the latter assumes byte ordering */
BO> This code was already reorganized completely.
Yes, I found this after I wrote my letter. But this is only example,
how to code may be enhanced with help of mentioned macros.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id│66&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
