Gpc

gpc@gnu.de

5400 discussions

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

Re: 2 suggestions about Units
by Frank Heckenbach 10 Nov '97

10 Nov '97

Hans Ecke wrote: > [...] > > unit communication(graph,keyboard,mouse); > > interface > > ...no interface because its unchanged > ...new/changed procedures or variables would be declared here Should there be a way to "hide" some of the other units' declarations, i.e. not export all of them? If so, any ideas, how? > begin > assign(logfile,`log`); > rewrite(logfile); > > inherited begin; (*or inherited init? or inherited main? Don't know > which is better*) I don't think this should/must/may be written at all. The initalization code of the other units will be called, anyway, before the code of this unit. I don't think there's any reason to change this, since it's good practice (also in OOP) to do the "inherited" initialization *before* one's own initialization (and the inherited finalization after one's own finalization). BTW: Does GPC already make sure that unit initializations/finalizations happen in this order? Otherwise, this might cause problems in some programs. > New syntax-elements needed : 1.) "unit foo(bar1,bar2,..);" > 2.) "inherited <someprocedure>;" > Advantages are, that this new syntax is IMHO very intuitive and uses > existing keywords by carefully extending their meaning. True. > Discussion of the new syntax: > ---------------------------- > 1.) The "unit foo(bar);" part would be simple(?,IMHO): Its just that all > interfaces are put after each other in order of appearence. I think (hope) so. This certainly seems useful. > 2.) The "inherited <someprocedure>;" part should be possible too. You have > procedure-overloading. As far as I know from C++ this is implemented by > translating names of procedures : > > procedure foo(s:string) -> asmname "foostring" (the identifier in the) > procedure foo(i:integer) -> asmname "foointeger" (.o-file, just example) > > The .gpi-file includes a mapping asmname<->pascalname of all funtions that > the compiler can put a call to "foostring" for a command like > foo(`bar!bar??BAR!!`) and a call to "foointeger" for foo(10). I think, overloading of procedures for different parameters is not quite the same, but so-called "qualified identifiers" for procedures with the same name in different units are planned to be introduced until GPC 2.2, anyway. > Assuming our example, the compiler reads the line "inherited > putpixel(..);". It looks for the asmname of graph.putpixel and calls it. > Communication.putpixel then gets its own asmname which has to be different > from the one of graph.putpixel. Then, I agree, "inherited" procedures don't seem like a big problem. However, there is a big difference to a "real" virtual procedure. Namely, when the original Graph unit contains a call to putpixel (e.g. from a line drawing function), the compiler can't possibly know that putpixel will be "overriden", so it will call graph.putpixel. The overriden procedure would only be effective for units using Communication. For putpixel, it might be only an efficiency problem, but e.g. mouse events that are called from within the mouse unit would not be logged in your example. OTOH, real virtual procedures might be possible, too, but they will have to be marked as virtual in the *original* unit, and it will probably be more work to implement them. (The compiler would have to automatically generate something like the code I showed last time.) > There is the only question/problem I can see : We want to have one > interface - this meens only one file communication.gpi. What with the > object-files? Just leave them as (see example) graph.o,keyboard.o,mouse.o > or build a librarie communication.a? I think that's left to the programmer (when GPC will be able to produce libraries). Either he takes the several .o files, or makes a library out of them. However, there seem to be some problems (technical and syntactical) to be solved for letting GPC produce libraries. > Also a problem with the librarie : What to do with generic units which > will be included often - like system.o or crt.o - include them into the > librarie? Also left to the programmer. But I would advise him not to do so, since when they will be updated, the user should have a chance to use the updated versions instead of the ones built into the library. Also, I'm not sure what happens when one uses several libraries that each include system.o. And, please note the conditions of the LGPL under which system and crt are. If he includes their binary files, he has to provide their sources, too. Therefore, it might be easier for him, just to point to or include the complete BPCompat package. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Backflips, cartwheels, and proc params...
by Orlando Llanes 10 Nov '97

10 Nov '97

Let's say I have a record as follows: TYPE ToeFoo = PACKED RECORD { Is PACKED neccessary to keep it continuous? } 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 :} 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. Again for the curious, I typed in the following code: PROGRAM VGA; USES DPMI; VAR Regs : __dpmi_regs; BEGIN Regs.x.ax := $03; __dpmi_simulate_real_mode_interrupt( $10, Regs ); END. 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. See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve/homepages/Monkey414

1 0

Re: Separate Compilation
by richard.kerry＠quantel.com 10 Nov '97

10 Nov '97

According to richard.kerry(a)quantel.com: > > Hello, > Could somebody please either : > 1. Direct me to - info -f gpc -n "Source structures" info -f gpc -n "Extensions" > or : > 2. Send me - > a comprehensive explanation of separate compilation using gpc, including > examples that clearly show which bits are in different files and how the > other bits pick up their definitions. And also including any > alternate/non-standard/old-fashioned techniques that are still usable. > I am working on a very large project, developed using Oregon Pascal. The > separate compilation is done by each module (eg fred.pas) having a header > file (eg fred.def) containing all the procedures, functions, types and > constants it wishes the rest of the world to know about. All the routines > in the header are 'external'. The modules all contain their own global > variables; if any need to share, this is done by access procedures, or > records shared via pointers. There is no > module/unit/import/export/interface/implementation system involved. The > modules are compiled individually, using #include (%include in Oregon) to You can also use (*$i Foo *) or (*$include "foo.pas" *) or (*$include <foo.pas> *). > pick up any external definitions and references required, and then linked. > I want to mechanically translate all these modules to gpc, so I'd prefer a > mechanism, if there is more than one available, that uses a structure as > similar as possible to the one we are currently using. The closest approximation to Oregon Pascal (as you describe it) which is currently possible with GNU Pascal is to use the "somewhat simpler GPC modules" described in `info -f gpc -n Extensions'. will have the desired effect ... uh - sh** (sorry!) it does not work! :-( :-( While implementing other things I threw away this one. The reason is that this feature turned into a bug when using Extended Pascal Modules or UCSD/Borland Pascal Units. Okay, this "GPC specific module" is very close to yet another type of Module defined in the PXSC standard. The only difference is that PXSC wants the reserved word `global' in front of each declaration that is to be exported. That's certainly more reasonable than to export just everything (like GPC did until February 1997 or so). It is planned to implement these PXSC modules into GPC. So you can either wait until GPC will have PXSC modules or use UCSD/Borland-style Units or Extended Pascal Modules. --------------------- Would it be possible to have a patch to re-enable the 'somewhat simpler' format, perhaps on a compiler switch ? The formatter program I am modifying to do our Oregon-to-GPC conversion doesn't have a symbol table that can be used to determine which routines are internal or external, so I prefer the syntaxes (is that a word ?) that don't need only the externals to be marked (global), or all to be bunched together or the definitions to be duplicated again (interface, implementation). That is to say I'd prefer to be able to use such a syntax at this stage so I can pass over three hundred modules through the conversion and not require every one of them to be hand-tweaked. I'd consider this a first stage of conversion, and expect to gradually convert them all to proper (Extended) syntax over a period of time. ----------------------- When is PXSC syntax likely to be available ? ----------------------- What's fatal signal 11 ? I've been changing my program to use separate compilation, rather than just $including all the bits of source it needs. I'm changing it to UCSD/Borland unit form, as I understand it from the Info and Peter's reply, and I get : 'gpc: Internal compiler error: program gpc1 got fatal signal 11' when I try to compile the unit. 'gpc fred.pas -o fred.o -v' gives : Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/specs gpc version 971001(2.7.2.3) /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) fred.pas /tmp/cca13174.i GNU CPP version 971001(2.7.2.3) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/i586-pc-linux/include /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/include /usr/include End of search list. /usr/local/lib/gcc-lib/i586-pc-linux/2.7.2.3/gpc1 /tmp/cca13174.i -quiet -dumpbase fred.pas -version -famtmpfile=fred.gpc -o /tmp/cca13174.s GNU Pascal version 971001(2.7.2.3) (i386 Linux/ELF) compiled by GNU C version 2.7.2.3. gpc: Internal compiler error: program gpc1 got fatal signal 11 I hope you can help. Richard.

1 0

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

10 Nov '97

According to Clyde Meli: > > I don't think my previous post got through - If they did please excuse this > repetition. It did come through. ;-) > I'm having problems compiling the beta under Solaris 2.5.1/gcc 2.7.2.3 > - I had problems with gcc 2.7.2.1 also so I installed gcc 2.7.2.3. > > /usr/local/bin/gcc -c -DIN_GCC -DGPC -DSVR4 -O3 -I. -I.. -I. -I./.. -I./.. > /config gpc-lex.c > In file included from gpc-lex.c:102: > hash.h:122: `AND_' undeclared here (not in a function) > [...] Uh - sorry - `parse.h' in `gpc-971001.tar.gz' is broken. :-( You can reconstruct it from `parse.y' using `bison', but since this didn't happen automatically during you compiled GPC, I assume that you cannot use `bison' on that machine. But never mind: Since `parse.h' is pretty short, I include it below. Hope this helps, 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< ---- parse.h for gpc-971001 ----------------------------------------------- typedef union { char *filename; long itype; int lineno; enum tree_code code; tree ttype; } YYSTYPE; #define IDENTIFIER 258 #define AND_ 259 #define ARRAY 260 #define BEGIN 261 #define CASE 262 #define CONST_ 263 #define DIV_ 264 #define DO 265 #define DOWNTO 266 #define ELSE 267 #define END 268 #define FILE_ 269 #define FOR 270 #define FUNCTION 271 #define GOTO 272 #define IF 273 #define IN 274 #define LABEL 275 #define MOD_ 276 #define NIL_ 277 #define NOT_ 278 #define OF 279 #define OR 280 #define PACKED 281 #define PROCEDURE 282 #define PROGRAM 283 #define RECORD 284 #define REPEAT 285 #define SET_ 286 #define THEN 287 #define TO 288 #define TYPE 289 #define UNTIL 290 #define VAR 291 #define WHILE 292 #define WITH 293 #define AND_THEN 294 #define BINDABLE 295 #define EXPORT 296 #define IMPORT 297 #define MODULE 298 #define ONLY 299 #define OR_ELSE 300 #define OTHERWISE 301 #define POW 302 #define RESTRICTED 303 #define PROTECTED 304 #define QUALIFIED 305 #define VALUE 306 #define OP_ABSTRACT 307 #define OP_CLASS 308 #define OP_CONSTRUCTOR 309 #define OP_DESTRUCTOR 310 #define OP_INHERITED 311 #define OP_IS 312 #define OP_PROPERTY 313 #define OP_VIEW 314 #define D_EXTERNAL 315 #define D_FORWARD 316 #define UCSD_SEGMENT 317 #define BP_EXPORTS 318 #define BP_INDEX 319 #define BP_INLINE 320 #define BP_INTERRUPT 321 #define BP_LIBRARY 322 #define BP_OBJECT 323 #define BP_OVERLAY 324 #define BP_PRIVATE 325 #define BP_PUBLIC 326 #define BP_RESIDENT 327 #define BP_SHL 328 #define BP_SHR 329 #define BP_UNIT 330 #define BP_USES 331 #define BP_XOR 332 #define ALL 333 #define RENAME 334 #define SYMMETRIC_DIFF 335 #define STRING_KEYWORD 336 #define IMPLEMENTATION 337 #define INTERFACE 338 #define D_ASMNAME 339 #define D_ATTRIBUTE 340 #define D_C 341 #define D_C_LANGUAGE 342 #define D_EXTERN 343 #define D_OVERRIDE 344 #define D_STATIC 345 #define BP_ABSOLUTE 346 #define BP_VIRTUAL 347 #define r_WRITE 348 #define r_READ 349 #define r_INITFDR 350 #define r_LAZYGET 351 #define r_COLLECT 352 #define r_POW 353 #define r_EXPON 354 #define z_ARCTAN 355 #define z_COS 356 #define z_EXP 357 #define z_LN 358 #define z_SIN 359 #define z_SQRT 360 #define z_POW 361 #define z_EXPON 362 #define p_INPUT 363 #define p_OUTPUT 364 #define p_REWRITE 365 #define p_RESET 366 #define p_PUT 367 #define p_GET 368 #define p_WRITE 369 #define p_READ 370 #define p_WRITELN 371 #define p_READLN 372 #define p_PAGE 373 #define p_NEW 374 #define p_DISPOSE 375 #define p_ABS 376 #define p_SQR 377 #define p_SIN 378 #define p_COS 379 #define p_EXP 380 #define p_LN 381 #define p_SQRT 382 #define p_ARCTAN 383 #define p_TRUNC 384 #define p_ROUND 385 #define p_PACK 386 #define p_UNPACK 387 #define p_ORD 388 #define p_CHR 389 #define p_SUCC 390 #define p_PRED 391 #define p_ODD 392 #define p_EOF 393 #define p_EOLN 394 #define p_MAXINT 395 #define p_TRUE 396 #define p_FALSE 397 #define p_EXTEND 398 #define p_UPDATE 399 #define p_SEEKWRITE 400 #define p_SEEKREAD 401 #define p_SEEKUPDATE 402 #define p_READSTR 403 #define p_WRITESTR 404 #define p_BIND 405 #define p_UNBIND 406 #define p_HALT 407 #define p_GETTIMESTAMP 408 #define p_ARG 409 #define p_RE 410 #define p_IM 411 #define p_CARD 412 #define p_CMPLX 413 #define p_POLAR 414 #define p_EMPTY 415 #define p_POSITION 416 #define p_LASTPOSITION 417 #define p_LENGTH 418 #define p_SUBSTR 419 #define p_TRIM 420 #define p_EQ 421 #define p_LT 422 #define p_GT 423 #define p_NE 424 #define p_LE 425 #define p_GE 426 #define p_BINDING 427 #define p_DATE 428 #define p_TIME 429 #define p_MAXCHAR 430 #define p_MAXREAL 431 #define p_MINREAL 432 #define p_EPSREAL 433 #define ucsd_CONCAT 434 #define bp_ASSIGN 435 #define bp_GETMEM 436 #define bp_FREEMEM 437 #define bp_INC 438 #define bp_DEC 439 #define bp_NEAR 440 #define bp_FAR 441 #define PXSC_OPERATOR 442 #define gpc_ASSIGNTYPE 443 #define gpc_MIN 444 #define gpc_MAX 445 #define STANDARD_OUTPUT 446 #define STANDARD_INPUT 447 #define op_COPY 448 #define op_NULL 449 #define op_ROOT 450 #define op_SELF 451 #define op_TEXTWRITABLE 452 #define ASM_KEYWORD 453 #define BREAK 454 #define CONTINUE 455 #define p_INDEX 456 #define p_MARK 457 #define p_RELEASE 458 #define RETURN_ 459 #define RESULT 460 #define EXIT 461 #define DEFAULT 462 #define OTHERS 463 #define p_CLOSE 464 #define SIZEOF 465 #define BITSIZEOF 466 #define ALIGNOF 467 #define TYPEOF 468 #define ANDAND 469 #define CONJUGATE 470 #define p_DEFINESIZE 471 #define gpc_GETFILE 472 #define INLINE 473 #define EXTERNAL 474 #define ASMNAME 475 #define VOLATILE 476 #define STATIC 477 #define G_CONST 478 #define TQ_BYTE 479 #define TQ_SHORT 480 #define TQ_LONG 481 #define TQ_LONGLONG 482 #define TQ_UNSIGNED 483 #define UNSIGNED_INTEGER 484 #define STRING_LITERAL 485 #define CHAR_LITERAL 486 #define UNSIGNED_REAL 487 #define GTE 488 #define LTE 489 #define NEQ 490 #define EXPON 491 #define CARET 492 #define CONST_EQUAL 493 #define CEILPLUS 494 #define CEILMINUS 495 #define CEILMULT 496 #define CEILRDIV 497 #define FLOORPLUS 498 #define FLOORMINUS 499 #define FLOORMULT 500 #define FLOORRDIV 501 #define ASSIGN 502 #define LBRACKET 503 #define RBRACKET 504 #define TWODOTS 505 #define ELLIPSIS 506 #define UNIMPLEMENTED 507 extern YYSTYPE yylval; #define YYEMPTY -2

1 0

Re: 2 suggestions about Units
by Peter Gerwinski 10 Nov '97

10 Nov '97

Hallo, Hans! Hello, everybody! According to Hans Ecke: > > [...] > > 1.) The "unit foo(bar);" part would be simple(?,IMHO): Its just that all > interfaces are put after each other in order of appearence. > > 2.) The "inherited <someprocedure>;" part should be possible too. You have > procedure-overloading. Not yet, but we are planning to have it in gpc-2.2. > [...] > > Assuming our example, the compiler reads the line "inherited > putpixel(..);". It looks for the asmname of graph.putpixel and calls it. > Communication.putpixel then gets its own asmname which has to be different > from the one of graph.putpixel. No problem with this, but what about, say, a `Circle' procedure in `graph.o'? Of course, you want it to use `Communication.PutPixel' instead of `Graph.PutPixel'. This change can only be done if `graph.o' is either recompiled or calls `PutPixel' through a pointer. Since calling functions through pointers is slower than a direct call and has other drawbacks, it is undesireable to make this the default for every unit. A more realistic approach would be to declare `PutPixel' in `Graph' as `virtual', so the compiler will make this one a pointer and assign the default value of `Graph.PutPixel' to it. Perhaps it would be desirable to have this feature built into the compiler, but (sorry if I repeat parts of my last mail): * You can do this manually right now by declaring Var PutPixel: Procedure ( x, y, color: Integer ) value Graph_PutPixel; and setting `PutPixel:= Communication_PutPixel' in the initialization part of the `Communication' unit. * You can do it by letting the unit export an object with a virtual method `PutPixel' and do all your graphics through the methods of this object (in a `with' statement). I am currently writing such a thing - it's much nicer than the "traditional" approach because you can have more than one graphics output device at the same time(-: with Screen^ do begin ClearScreen; Line ( 0, 0, GetMaxX, GetMaxY ); end (* with *); with Printer^ do begin ClearScreen; Line ( 0, GetMaxY, GetMaxX, 0 ); end (* with *); What I mean is: I do not see a real need for such a new feature, so it is, IMHO, not worth the effort to implement it and - perhaps even more important - not worth the problems arising from the introduction of yet more incompatibilities between GPC and other existing compilers and standard specifications. (* But if you are interested in joining the GPC development team for doing the necessary changes to GPC, this would eliminate at least the first argument. ;*) Schoene Gruesse, 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: Weird ASM error...
by Peter Gerwinski 10 Nov '97

10 Nov '97

According to Orlando Llanes: > I'm using the latest GPC Beta (971101?), and when I type in the following > fragment of code: > > PROGRAM Foo; > BEGIN > asm('movl %eax, 0xa0000' ); > END. > > it compiles fine, but when I run it, the program reports a GPF. [...] This means to store the contents of the `eax' register at the absolute address $A0000. Perhaps you mean `movl $0xA0000, %eax' which means to move the value $A0000 into the `eax' register? Since GPC-compiled programs run in protected mode, you cannot simply access the VGA memory by specifying an absolute address, if that is what you wish to do. Hope this helps, 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

Jump to page:

2025

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