DPMI calls (Was: Re: Backflips, ...)...

Frank Heckenbach heckenb at mi.uni-erlangen.de
Tue Nov 11 21:59:06 CET 1997


Orlando Llanes wrote:

> > On the x86 platform, it is. All variables (global, local and dynamic) and
> > code are in the same segment, and pointers and references are just 32-bit
> > offsets. (On other platforms, there may not be anything like Descriptors, or
> > pointers may have a different size, e.g. 64 bits.)
> 
>     Cool :) Where can I Get info on the Machine specifics of Alphas? I
> want to know the low level details like how graphics are displayed, if
> sound is available, the architecture of the memory (for example: PC has
> segments, offsets, etc).

Though I can't really give you any information about this, and Peter gave
you some, I just want to remak that these things are not actually dependent
on the processor, but on the other hardware and the OS. While I don't know if
there's more than one hardware architecture with Alphas, I'm quite sure that
there are different OS's running on the Alpha.

> > Unfortunately, there is something wrong there, namely the declaration of
> > __dpmi_regs. Instead of ShortCard (16 bit unsigned integers on the x86, and
> > the natural translation of the "unsigned short" of dpmi.h), it uses Bytes for
> > the 16-bit registers. Try changing it as below. (I did not check your program,
> > however, because I'm too lazy now to boot DosEmu... ;-)
> 
>     Doh! It's *always* those dang pesky minor details that are so elusive,
> the ones that you would never think could possibly go wrong :P One thing
> tho, I think I tried it using the following declarations (and I changed
> the sizes accordingly as well): 
> 
> TYPE
>   DWord = Cardinal(32);
>   Word  = Cardinal(16);
>   Byte  = Cardinal(8);
>
> So what said Byte previously, I changed to Word, and what was Word
> previously I changed to DWord. I'll try it again, mayhaps I did something
> wrong :}

These declarations seem OK, they always guarantee the correct register sizes
(in constrast to the other types which are merely a 1-to-1 translation of the
types used in the C header; they might be different on other platforms, but
then, for DPMI specific code, that's not much of an issue...). However, I
would not call it "Word" because in a 32-bit environment, some people would
expect a "Word" to have 32 bits (as the built-in Word type does). Perhaps
something like "Word16", to avoid possible confusion...

> > BTW: "Packed" is (I think) not necessary for this record, because all fields
> > are aligned, anyway, i.e. 32-bit fields are preceeded only by other 32-bit
> > fields, and so on. The original record is a "struct" in dpmi.h, and I think
> > C's "struct"s correspond to non-packed records in Pascal. Is this right?
> 
>     Does Packed align on a Dword boundary? Or does it lump all the fields 
> together to ensure that they are continuous? I ask because from what I 
> remmeber about Pascal, it's to keep them continuous (the only time in 
> Borin... errr... Standard Pascal that I've seen Packed is for a character 
> array).

Yes, it keeps them together. What I meant is: since the fields are aligned,
anyway, even a non-packed array would not insert any gaps, so it doesn't
matter here if packed or non-packed. Since the corresponding function was
written in C, it has to use non-packed "struct"s, so a non-packed array would
be the 1-to-1 translation into Pascal.

>     Ok, I think I figured out what went wrong. Apparently in C, the way 
> __dpmi_regs is defined is in a way such that the 3 sections (d, x, and h) 
> overlap, but it doens't appear to be overlapping in Pascal. I noticed a 
> quirk with Borland Pascal, and I was wondering if it was present in GPC, 
> when you define a record structure as follows:
> 
> TYPE
>   MyRec = RECORD
>     CASE Integer OF
>       0 : (SomeVar : Integer; SomeVar2 : Integer);
>       1 : AnotherVar : ARRAY[ 1..2 ] OF Integer;
>     END;
>   END;
>
> Supposedly, you want to tell the compiler to use SomeVar, or AnotherVar
> as if they were overlapping. An Integer is 16 bits in BP, with that in 
> mind, BP would report 8 when you use SizeOf( MyRec ), logically it should 
> be 4. By overlapping, I mean like a type cast. Is there a way to do this 
> in GPC like C apparently does?

Variant records *are* overlapping in Pascal (both BP and GPC). I don't know
what you tried, but the following program gives 8 in GPC and 4 in BP, both
as I expected for an overlapping type.

program x;
 TYPE
   MyRec = RECORD
     CASE Integer OF
       0 : (SomeVar : Integer; SomeVar2 : Integer);
       1 : (AnotherVar : ARRAY[ 1..2 ] OF Integer);
   END;

begin
  writeln(sizeof(myrec))
end.

If you still don't get the program working, please post a complete program
that tries to set the mode, so we can try it.

Kevin A. Foss wrote:

> >> Is there anything in C that corresponds to packed records in Pascal?
>
> [...]
>
> However there are a lot of caveats, like you can only use integer
> types, and the behavior if a field crosses a word boundry is
> implementation defined.  So it would take a lot of work to simulate
> anything but the simplest Packed Pascal records--although I lost where
> the discussion began so I don't know for what reason you want to pack
> things in C.

Nothing particular, just curiosity. Thanks for the info.

-- 
Frank Heckenbach, Erlangen, Germany
fjf at gmx.de
http://home.pages.de/~fjf/links.htm




More information about the Gpc mailing list