TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: Adam Fitzpatrick
from: Frank Adam
date: 1996-07-21 07:17:00
subject: Regs

G'Day Adam,
 
-=> Quoting Adam Fitzpatrick to Frank Adam <=-
 
 FA>Just curious why is REGS a union and not a struct ? It feels like one.. 
 AF> It's a union of two structs I think. :) This is because AX is divided
 AF> think I've explained this very clearly, but you should be able to
 AF> figure it out. 
Of course :-) I think i do know that part of it.
 
 FA> char* Get_DTA() 
 FA> regs.x.ax = 0x2f00;

 AF> Since you only need to set AH, you could change this. It won't help,
 AF> but it'll be "more correct". (I don't like wasting a
byte; just one of
Wouldn't that byte already be wasted ? 
AFAIK, Memory will be allcated for the largest unit in unions, in 
REGS that's the regs.x struct. 
Basicly this is what i was wondering about when i asked the question.
I have a feeling that if i'd access regs.h.al, the union's byteregs 
structure would get filled, than when i access regs.x.ax it would have 
to fill the wordregs struct. So if this is for saving bytes, i'd rather 
waste the a few bytes and have them in separate structs, and not in 
a union.( i think... :) )
                                                                        
 AF> have a look at the definition of REGS again for something like
 AF> regs.h.ah or regs.l.ah. (That'll explain why it's a union I think.)
The byteregs struct holds both the low and high bytes.

 
 FA> ptr = (char far*) MK_FP((unsigned)sregs.es,(usigned)regs.x.dx);

 AF> Two problems:
 AF> 1) It doesn't return ptr.
No it returns seg:off, but that's what MK_FP turns into a ptr.

 AF> 2) According to my docs, the INT 21h call returns the address in
 AF> ES:BX, not ES:DX.
Yes, i've checked again and it is BX.

 AF> How about (completely untested):

 AF> char* Get_DTA()
 AF> {
 AF> char* dta;
 

 AF> I've always believed you should use assembly language for an assembly
 AF> language job like this. Those regs and int86x things annoy the hell
 AF> out of me for some reason - I can _feel_ the time wasted passing
 AF> parameters and calling the procedure and loading the registers. :)
 
Funny i've had no problems reading that code, but i'd probably never manage 
to write it at the present.
The few feeble attempts i've had at assembly were with rather poor 
results, and i guess it did put me off to a large degree.

 AF> Anyway, the pushes and pops preserve all the registers that should be
 AF> affected, because I'm not sure which ones the compiler really needs you
 AF> to save. 
 AF> The syntax of [word ptr dta] (and the next line) might need changing;
 AF> perhaps word ptr [dta] might be better (I'm used to TASM's ideal mode
 AF> syntax, which is different from MASM's standard. It works in TP6
Thanks for that snip,i'll try it. I do use TASM when i have to.
I may have to see if i can get the hang of this assembly thingo, but
chances are i didn't get much better at it since the last time :-)


  L8r Frank (fadam{at}ozemail.com.au).
  
___ Blue Wave/DOS v2.21
                                                  

---
* Origin: Melbourne PC User Group BBS (3:632/309)
SEEN-BY: 3/103 50/99 620/243 623/630 632/50 107 108 309 348 360 371 504 525
SEEN-BY: 632/530 533 562 633/371 634/388 396 635/301 502 503 506 544 639/252
SEEN-BY: 711/401 409 410 413 430 808 809 932 934 712/515 713/888 714/906
SEEN-BY: 800/1
@PATH: 632/309 107 635/503 50/99 711/808 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.