Gpc November 1997

gpc@gnu.de

32 participants
113 discussions

Re: DPMI calls (Was: Re: Backflips, ...)...
by Frank Heckenbach 11 Nov '97

11 Nov '97

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(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: GPC and GPT
by Frank Heckenbach 11 Nov '97

11 Nov '97

In news:comp.lang.pascal.borland, Brian Jones <brijones(a)usa.net> wrote: > I have copies of both GPC and GPT, along with RH-IDE and the GNU binutils, > as well as almost the rest of the entire DJGPP collection. I have tried to > write programs in Pascal using RH-IDE, and have had success getting them to > compile, but I can't get them to link (although I can get programs written > in C to link). My question is this, has anyone else had this same problem, > or does anyone know how to fix this? When replying, it's probably necessary to CC a copy to the poster. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: DPMI calls (Was: Re: Backflips, ...)...
by Peter Gerwinski 11 Nov '97

11 Nov '97

According to Orlando Llanes: > 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; This is not a quirk but a variant record which is even part of the ISO standard. (Hmmm ... so maybe it "must" be a quirk?;-) (BTW, you have one superfluous `END' in the above.) > 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? GPC accepts this, just like BP or any other Pascal compiler does. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Turbo/Free Vision --- or EFLIB
by Johan Larsson 11 Nov '97

11 Nov '97

[ EFLIB vs. Free Vision for FPK Pascal ] Hi Daniel Mantione and everybody, Pierre Phaneuf writes: >> EFLIB to be crushed by advanced capabilities, extreme flexibility >> and out-of-this-world performance! ;-) Daniel Mantione writes: >> What do you think of making EFLIB as a supplement to the objects unit? Daniel: yes - and no, depending on how to interprete ;-) your question! EFLIB will never be written to be compatible with Turbo Vision: let me explain why! The goal with EFLIB is to create a standardized class library. But as Pierre said, we also aim to create an extreme flexibility as well as modularity and code reusability - and simplicity. These are the main goals with EFLIB - not to follow existing standards thus limiting the new thinking and Java-alike solutions, event mechanisms, design patterns and so on. The only consideration that affect the way EFLIB will evolve is **what is the best solution**. "What is the best backward compatible solution" is of little or no concern (with one exception; backward compatiblity to earlier EFLIB releases starting with the first official release, but that will be a piece of cake when the modular interface is set). Let me give concrete examples. When classic data structures are designed, we do not look at traditional solutions and try to follow the expectations of the user. Instead, we find the solution we prefer, and try to package that solution in a simple interface and an intuitive design. Iterator classes for the data structures are one example. Hash table class hierarchy is one. ADT inheritance is yet one. But there is one thing that may be of interest for you. Since the capabilities of Turbo Vision (or Free Vision) is likely to be a subset of the capabilities of EFLIB, we could (with help from some Turbo Vision enthusiast of course) create classes that ***emulate Turbo Vision*** within EFLIB. The same goes with other features in EFLIB; for example the extended stream engine to be designed by Pierre Phaenuf or the GUI components to be designed by Aleksandar Dlabac and Miroslav Kharchuk - or anything else. We could provide a complete set of Turbo Vision (read: Free Vision) classes built on the modular and standardized EFLIB solutions. Thus, we can provide a dual interface so that old users can make use of the new features... But then, I'd rather see that you all learned EFLIB straight from the start... But I guess that never will happen --- ;-) Best Regards, Johan Larsson E-MAIL jola(a)ts.umu.se, EFLIB(a)ts.umu.se, EFLIB-Developers(a)ts.umu.se, EFLIB-Users(a)ts.umu.se HOME http://www.ts.umu.se/~jola/ Also, REMEMBER to check out http://ftp.sunet.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED. Also, Subscribe to the EFLIB mailing lists! See http://www.ts.umu.se/EFLIB/Lists/.

1 0

Re: Backflips, cartwheels, and proc params...
by Peter Gerwinski 11 Nov '97

11 Nov '97

According to Orlando Llanes: > > 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). [...] See the source (and its documentation) of the Linux kernel for the Alpha. > BTW, are there plans to port DJGPP and/or GPC to > the Mac platform? Are there any free tools you or anybody know of that > compile on it? AFAIK, the GNU project does not support the Mac platform because Apple did not give them the necessary information. > 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 :} `Byte' always has the smallest size direcly accessible to the processor anyway - usually eight bits ... > Does Packed align on a Dword boundary? Or does it lump all the fields > together to ensure that they are continuous? The second. Without `packed', you get the first. > 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). It does not stop there: Try the following with BP and with GPC: Var foo: packed array [ 1..64 ] of Boolean; writeln ( SizeOf ( foo ) ); :-) > Got me on that one :( Although I am very familiar with the types, > type definitions, and I haven't seen anything really about packing the > records like in Pascal. I could be wrong tho, if there is something, it's > one of those deep dark secrets of C :P There are bit fields: struct foo { int i : 4; unsigned j : 2; int k : 1; unsigned l: 1; } is the same as the following in Pascal foo = packed record i: -8..7; j: 0..3; k, l: 0..1; end (* foo *); and both fit in a single byte. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Binary installation
by Peter Gerwinski 11 Nov '97

11 Nov '97

According to Tom Dye: > > There might be another problem. The following code once compiled, but > doesn't now. > > *** code snippet *** > > module bug interface; > > export > bug = (StrPCopy); > > const > LONGEST_STRING = 256; > > type > Any_String = String(LONGEST_STRING); > CString = __cstring__; > > function StrPCopy (Dest : CString; Src : Any_String) : CString; > > end. > > module bug implementation; > [...] > function StrPCopy (Dest : CString; Src : Any_String) : CString; Since `Any_String' isn't exported, the implementation module does not know about it. (Should it? What does the standard say about this?) You can either export `Any_String' or change `StrPCopy' to accept just a `String' parameter. The latter method did not work in gpc-2.0 but is in fact the correct way to pass an arbitrary string. function StrPCopy (Dest : CString; Src : String) : CString; or function StrPCopy (Dest : CString; Const Src : String) : CString; Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: probs compiling current beta GPC
by Peter Gerwinski 11 Nov '97

11 Nov '97

According to Clyde Meli: > /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.3/include/unistd.h:230: conf > licting types for `rename' > /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.3/include/stdio.h:161: previ > ous declaration of `rename' It seems as if the (AutoConf) configuration script did not recognize your system correctly. Please try and edit `gpc-config.h' manually and flip the `HAVE_UNISTD_H' switch. Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Backflips, cartwheels, and proc params...
by Kevin A. Foss 11 Nov '97

11 Nov '97

On Mon, 10 Nov 1997 18:54:57 -0500 (EST), Orlando Llanes wrote: >> Is there anything in C that corresponds to packed records in Pascal? > > Got me on that one :( Although I am very familiar with the types, >type definitions, and I haven't seen anything really about packing the >records like in Pascal. I could be wrong tho, if there is something, it's >one of those deep dark secrets of C :P Well, it won't be totally analogous to a packed record in Pascal, but you can of course define bit fields for variables. The C standard also allows padding by putting in x # of bits assigned to an unnamed field in order to fill out a byte or word. Also, a bit width of 0 will force alignment on the next word boundry. {See the last section in Chapter 6 of K&R} So I think you could simulate packed records but you would have to do it by manually setting integers to specific bit-widths. In fact, K&R refers to bit-fields as a method to 'pack several objects into a machine word.' 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. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Binary installation
by Peter Gerwinski 11 Nov '97

11 Nov '97

According to Tom Dye: > > [...] This code, which compiled > previously, fails now with a message that there is an undeclared > identifier `Ch' in function Isalphanum on line 17. [...] I fixed it. :-) Patch below. Since this patch changes the GPI file format, you must recompile all your modules/units after having applied it. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005] 8< --------------------------------------------------------------------------- --- gpc-971106/p/module.c Sat Nov 1 03:30:22 1997 +++ gpc/p/module.c Sun Nov 9 21:02:24 1997 @@ -1186,7 +1186,7 @@ store_tree (DECL_NAME (t), s, depth + 1); /* name of function */ store_tree (DECL_ASSEMBLER_NAME (t), s, depth + 1); store_tree (TREE_TYPE (TREE_TYPE (t)), s, depth + 1); /* return type */ - store_tree (TYPE_ARG_TYPES (TREE_TYPE (t)), s, depth + 1); /* argument types */ + store_tree (DECL_LANG_SPECIFIC (t)->parms, s, depth + 1); /* arguments */ /* Machine attributes. */ for (a = TYPE_ATTRIBUTES (TREE_TYPE (t)); a; a = TREE_CHAIN (a)) @@ -1765,8 +1765,8 @@ * they already were prediscriminated before they were * written into the GPI file. */ - tree name = get_unique_identifier ("parm", 0); - d = build_tree_list (NULL_TREE, TREE_VALUE (a)); + tree name = DECL_NAME (a); + d = build_tree_list (NULL_TREE, TREE_TYPE (a)); d = build_tree_list (build_tree_list (d, name), build_tree_list (NULL_TREE, NULL_TREE)); push_parm_decl (d);

2 1

Re: Backflips, cartwheels, and proc params...
by Frank Heckenbach 11 Nov '97

11 Nov '97

Orlando Llanes wrote: > Let's say I have a record as follows: > > TYPE > ToeFoo = PACKED RECORD { Is PACKED neccessary to keep it continuous? } Yes, it is. If you want to verify for yourself, you can try something like var Foo: ToeFoo; begin {$x+} Writeln ( Pointer((a)Foo.BarNone) - Pointer((a)Foo.Bar) ) end. (works only with non-packed records). The type casts to Pointer are there to prevent GPC from assuming another base size than 1. > Bar : Byte; > BarNone : Word; > END; > The fields are not important, what is important is the following procedure: > > PROCEDURE DahDahDah( VAR aFoo : ToeFoo ); > BEGIN > END; > > I need to get a pointer to it in ASM in order to manipulate it and in > order to save the value. What would I have to do? Is it safe to assume > that DS = Descriptor to aFoo in procedure DahDahDah? And do VAR parameters > return a 32-bit offset? I remember it coming up once before that the > pointers were 32-bit offsets, but I just want to verify that I remembered > correctly :} 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.) > For the curious, what I'm doing is coding a DPMI Simulate Real Mode > Interrupt so I Can call RM ISRs, but especially to change the graphics > mode. I'm aware of BPCompat (BTW, AWESOME collection of routines Chief et > al! :), and I tried it, but although the procedure > __dpmi_simulate_real_mode_interrupt() executed properly, I didn't get the > desired video mode. Besides, I'm coding it myself because I want to keep > it simple. (* IMHO, it would be simpler to use existing units. *) > Instead of getting mode 3, I got mode 1 or 2 (I didn't check beyond > noticing that it didn't look like Mode-13h, it was some 40x20 characters > per screen, and it looked like a text mode). I honestly don't think it was > something wrong in the DPMI unit, the DPMI unit links to a C routine. 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... ;-) 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? Is there anything in C that corresponds to packed records in Pascal? -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm --- dpmi.pas Wed Oct 22 13:47:10 1997 +++ /dos/f/t/dpmi.pas Mon Nov 10 19:35:14 1997 @@ -68,23 +68,23 @@ ); x : ( - di, di_hi : Byte; - si, si_hi : Byte; - bp, bp_hi : Byte; - x_res, res_hi : Byte; - bx, bx_hi : Byte; - dx, dx_hi : Byte; - cx, cx_hi : Byte; - ax, ax_hi : Byte; - flags : Byte; - es : Byte; - ds : Byte; - fs : Byte; - gs : Byte; - ip : Byte; - cs : Byte; - sp : Byte; - ss : Byte; + di, di_hi : ShortCard; + si, si_hi : ShortCard; + bp, bp_hi : ShortCard; + x_res, res_hi : ShortCard; + bx, bx_hi : ShortCard; + dx, dx_hi : ShortCard; + cx, cx_hi : ShortCard; + ax, ax_hi : ShortCard; + flags : ShortCard; + es : ShortCard; + ds : ShortCard; + fs : ShortCard; + gs : ShortCard; + ip : ShortCard; + cs : ShortCard; + sp : ShortCard; + ss : ShortCard; ); h : (

2 2

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc November 1997