Gpc March 2000

gpc@gnu.de

28 participants
42 discussions

Re: Documentation formatting languages (was: Obscure features of GPC)
by tov are jacobsen 12 Mar '00

12 Mar '00

On Sat, 11 Mar 2000, Peter Gerwinski wrote: [...] > One could consider moving to DocBook (SGML) which can produce > GNU Texinfo (and TeX and HTML and whatever). > > Opinions? > DocBook is very nice for technical documentation, and it appears to be the standard for a lot of free software projects such as Linux, GNOME and KDE. Currently GNOME is using the SGML version, but they have standardized on not using the SGML shorthands like </> so that migration to XML will be painless. I think an upcomming version of the Help browser will support on-the-fly formating of DocBook documents. Information on the GNOME documentation project complete with a really nice getting started manual can be found here: http://www.gnome.org/gdp/ -- Tov Are Jacobsen

1 0

About gcc compatibility (again)
by Khimenko Victor 11 Mar '00

11 Mar '00

I catch this mail in lklm few minutes ago. It touches old subject: is it safe to use old libgcc.a or you need to use only proper version. Looks like I was right after all :-) At least for ARM. Note last paragraph from following mail. As I have no ARM I can not comment on it, but... -- cut -- 11-Mar-00 16:26 you wrote: >From sch57!vger.rutgers.edu!owner-linux-kernel-outgoing Sat Mar 11 19:57:25 2000 Received: by khim.sch57.msk.ru (UUPC/@ v7.00, 06Mar97) with UUCP id AA02326; Sat, 11 Mar 2000 19:57:25 +0300 (MSK) Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by dell.sch57.msk.ru (8.8.8/8.8.8) with ESMTP id TAA10429 for <linux-kernel(a)khim.sch57.msk.ru>; Sat, 11 Mar 2000 19:29:52 +0300 Received: from vger.rutgers.edu ([128.6.190.2]:13428 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]" smtp-auth: <none> TLS-CIPHER: <none>) by nic.funet.fi with ESMTP id <S5956AbQCKQgQ>; Sat, 11 Mar 2000 18:36:16 +0200 Received: by vger.rutgers.edu via listexpand id <S157604AbQCKM2o>; Sat, 11 Mar 2000 07:28:44 -0500 Received: by vger.rutgers.edu id <S160078AbQCKM1t>; Sat, 11 Mar 2000 07:27:49 -0500 Received: from p27-magpie-gui.tch.enablis.net ([194.168.180.27]:4470 "EHLO caramon.arm.linux.org.uk") by vger.rutgers.edu with ESMTP id <S157686AbQCKMYL>; Sat, 11 Mar 2000 07:24:11 -0500 Received: from raistlin.arm.linux.org.uk (root@raistlin [192.168.0.3]) by caramon.arm.linux.org.uk (8.9.3/8.9.3) with ESMTP id QAA18879; Sat, 11 Mar 2000 16:27:11 GMT From: Russell King <rmk(a)arm.linux.org.uk> Received: (from rmk@localhost) by raistlin.arm.linux.org.uk (8.7.4/8.7.3) id QAA07865; Sat, 11 Mar 2000 16:26:21 GMT Message-Id: <200003111626.QAA07865(a)raistlin.arm.linux.org.uk> Subject: Re: ADFS -> undefined reference to __cmpdi2 (2.3.51) To: matti.aarnio(a)sonera.fi (Matti Aarnio) Date: Sat, 11 Mar 2000 16:26:21 +0000 (GMT) Cc: Philip.Blundell(a)pobox.com (Philip Blundell), arjan(a)fenrus.demon.nl (Arjan van de Ven), linux-kernel(a)vger.rutgers.edu In-Reply-To: <20000311180544.E13396(a)mea.tmt.tele.fi> from "Matti Aarnio" at Mar 11, 2000 06:05:44 PM X-Location: london.england.earth.mulky-way.universe X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Sender: owner-linux-kernel(a)vger.rutgers.edu Precedence: bulk X-Loop: majordomo(a)vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Lines: 35 Content-Type: text/plain; charset=us-ascii Content-Length: 1585 Matti Aarnio writes: > As Linus hasn't put it into i386 (nor Alpha), he has > some good reason. Ask him for guidance. That is probably because libgcc contained some stuff which was unsuitable for the kernel on x86. > Mainly I think we should NEVER use slow 64/* division routines > in fast paths. Ah, are you saying that the only thing that libgcc.a is used for is supposidly slow division routines? Some architectures need it for much much more than that. > As an end-result you will get your system free of need for > libgcc.a, and possible dangers lurking in it. No. libgcc.a is dependent on the compiler. I do know that code generated with one ARM gcc compiler does not work with the libgcc.a of a later compiler, suggesting that there is a difference in the API between the two versions of GCC. Hence, the only real way to get the correct behaviour in this case is to use libgcc.a for ARM. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk(a)arm.linux.org.uk --- --- | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ -- cut --

1 0

Re: FreeVision port to GPC: helpers needed
by Frank Heckenbach 10 Mar '00

10 Mar '00

Marco van de Voort wrote: > > > I mean that changing the TYPE of both methods will cause other procedures to > > > fail, causing an incompability with FV. > > > > > > Keeping the argument a untyped pointer, and then typecasting to a proctype will > > > probably not work, [...] > > > > It does work. > > How does it work effectively? So something like: > > procedure proc1(x:longint); > > procedure proc2(x:longint); > > begin > end; > > begin > end; > > type myproctype=procedure(x:longint); > > procedure proc3(x:pointer); > > begin > myproctype(x); (Missing argument here.) > end; > > begin > proc3(@proc1); > proc3(@proc2); > end; Like this, it won't work since proc2 isn't even visible to the main program. But you can call `proc3(@proc2);' from proc1 (if you declare proc3 before proc1, of course). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

FreeVision port to GPC: helpers needed
by Dr A Olowofoyeku 10 Mar '00

10 Mar '00

Hi all I have been having discussions with Leon de Boer who is writing most of the FreeVision (FV) stuff. The project is being done to dispense with all copyright issues, and it seems that this has largely been achieved. I have ported the Objects unit to GPC, along with a few other units. The sticking point now is a number of the base units (drivers.pas, dialogs.pas and views.pas), which contain some assembler code. Some of these are in x86 assembler and some (determined by some IFDEFs) are in FPC assembler (which looks to me like the AT&T syntax). Since I understand neither of these, I can't proceed with the porting. If you would like to help with porting these units, then do please get in touch. It would seem better to recode these assembler routines in Pascal than to convert the FPC assembler to something that GPC can understand (if it isn't already in that form). In my opinion, if we can port these three units to GPC, then a working class library for GPC (which also supports several other Pascal compilers) is within reach. Best regards, The Chief ----- Dr Abimbola A Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com Author of Chief's Installer Pro v5.22 for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm

4 11

Re: Obscure features of GPC
by Frank Heckenbach 10 Mar '00

10 Mar '00

Dr A Olowofoyeku wrote: > On 10 Mar 00, at 10:22, Mark Taylor wrote: > > > > Yes, the GPC documentation is lacking, that's perhaps the most > > > urgent problem. However, the `Integer (40)' feature in particular is > > > documented there under Reference/Integer. > > > > Do you mean the info database? Or the source code? > > I think he means the info database. Yes (though the same manual is also available in html, dvi and PostScript formats)... > > Can anyone recommend a list of documentation apart from the info > > database (I know about this), to help me having to pester people on > > this list with "novice" questions. > > > > I am trying to get myself "up to speed" with GPC and am finding it a > > bit problematic (I am a novice with GPC but not a novice programmer). > > Like Frank said, up-to-date documentation on GPC is currently a > major issue. Until one is produced, it seems that you have to find > any information you want from a variety of sources. This mailing list > and its archives is a good place to look. I have also found the stuff in > Frank's 'to do' pages (http://fjf.gnu.de/gpc-todo_toc.html) to be > informative. Thanks. ;-) Currently, it's often ahead of the actual releases (so check the dates on the new features and fixed bugs), but this will change with a CVS server... > Then the source code (especially the sources in the > 'units' directory). For the supplied units, this is recommended. For the RTS (i.e., libgpc), all public declarations can be found in gpc.pas -- except those routines that are called with compiler magic (mostly the predefined routines in the various language dialects). Frank PS (to all of you): No need to CC me personally. -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: GC & GPC question.
by Frank Heckenbach 10 Mar '00

10 Mar '00

Khimenko Victor wrote: > > The relevant hooks are GetMemPtr etc., declared in the GPC unit. You > > need them if you want to switch between different allocators. > > Hmm. It'll require locks in multithreaded program and will be not very > convenient. I see. BTW, are the normal malloc()/free() routines and Boehm's GC thread-safe, do they do their own locking? I can't guarantee that GPC's heap handling routines are thread-safe as I haven't used threads. At first sight, I'd say they are as long as you don't use Mark/Release, but if you want to check them (or other RTS routines) more throughly, you have the source... > Perhaps we can hide it over clever #define ? Let's try: > > -- cut -- > uses gpc; > #define gc_alloc(x) (begin var res:^x; save_ptr:GetMemType; save_ptr:=GetMemPtr; GetMemPtr:=GC_alloc; res:=new(x); GetMemPtr:=save_ptr; end) Since the variables are declared within a statement part, you'd need a second `var' before save_ptr. Also, Pascal's `New' is syntactically different from C's malloc(). `New' is only meant for typed pointers (simple types, schemata, objects), while `GetMem' takes a memory size, but will not initialize any fields of the structure. The correspondence is `p = malloc (n)' -> `GetMem (p, n)'. > Oops. Is it possible to use compound statement as expression in GPC somehow ? Not AFAIK. Only as an inline function. The following should work, but as I said, it will not initialize any fields, so it won't work for strings, schemata, files and other types that require initialization (but you could write a second routine specialized for strings, as shown). inline function GCAlloc (x : SizeType) = Res : Pointer; var save_ptr : GetMemType; begin save_ptr := GetMemPtr; GetMemPtr := @GC_alloc; GetMem (Res, x); GetMemPtr := save_ptr end; function GCAllocString (const s : String) = Res : PString; var save_ptr : GetMemType; begin save_ptr := GetMemPtr; GetMemPtr := @GC_alloc; New (Res, Length (s)); Res^ := s; GetMemPtr := save_ptr end; var i : ^Integer; s : PString; begin i := GCAlloc (SizeOf (Integer)); s := GCAllocString ('foo'); Writeln (s^); end. Of course, you could then hide then `SizeOf' in a macro with something like: {$define gc_alloc(x) GCAlloc (SizeOf (x))} > And BTW how I can continue #define on next line (C's \ in the end of line does > not work). {$define ...} can span multiple lines without any `\'. Peter Gerwinski wrote: > Khimenko Victor wrote: > > Hmm. It'll require locks in multithreaded program and will be not very > > convenient. Perhaps we can hide it over clever #define ? Let's try: > > [...] > > You need to EXPLICITLY change new strategy every time :-(( > > Especially annoying since you want to use GC_malloc_atomic for plain strings... > > [...] > > What about introducing a second `New' that allows the user to > pass an additional parameter to the allocator? Might be a solution. (Not that the syntax of `New' isn't already complicated enough... :-/) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 7

How to compile hello.pas for win32
by Mark Taylor 09 Mar '00

09 Mar '00

I tried converting this win32 hello.c program to pascal without success... #include <windows.h> int STDCALL WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) { MessageBox (NULL, "Hello, Windows!", "Hello", MB_OK); return 0; } I was getting undefined references to messagebox at the linking stage. To compile I did... gpc -mno_cygwin -mwindows whello.pas -o whello.exe Thanks, Mark. -- Mark Taylor, Department of Corporate Information & Computing Services, Extension 21145. (0114) 222 1145 http://www.shef.ac.uk/misc/personal/ad1mt The opinions expressed in this email are mine and not those of the University of Sheffield.

3 4

Re: GC & GPC question.
by Frank Heckenbach 09 Mar '00

09 Mar '00

Khimenko Victor wrote: > This is NOT what you usually want. GC ALWAYS has penatly over "normal" > malloc/free way. Yes, there are benefits as well but when you are using > third-party library where malloc/free already used then with GC's replacement > you'll get slowdown and nothing more. In case of C it's all simple: just > use malloc/free and gc_alloc as desired. In case of C++ overloaded new can > be used for this purpose. In case of GPC you can have GC-enabled new (with > GC's malloc) or non GC-enabled new bot not both :-/ You can not just use > gc_alloc(sizeof(record)) since if record has embedded strings or files > you need to initialize it first (and if record has virtual part then new > can allocate less then gc_alloc(sizeof(record)) -- or is this Pascal's feature > not implemented yet?). So the question is: is it possible to use another > allocator (and deallocator) in GPC's new ? Something akin to > field:=new(malloc,OldNormalNonGcClass); > ptr:=new(gc_alloc,TestClass); > dispose(free,field); > > Something like this was discussed when shred memory allocation problem was > discussed but I can not find it :-/ The relevant hooks are GetMemPtr etc., declared in the GPC unit. You need them if you want to switch between different allocators. By default, AIUI, Boehm's GC, when linked in, will be used for all allocations without further action on the Pascal side. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 3

Re: GC & GPC question.
by Frank Heckenbach 09 Mar '00

09 Mar '00

Khimenko Victor wrote: > 7-Mar-00 18:57 you wrote: > > One of the things that steers me away from Borland Pascal is its lack > > of a runtime garbage collector. > > > Does GNU Pascal have a runtime garbage collector? > > No. To All: perhaps something can be done here ? Boehm's GC will work just fine > with GPC in simple cases but if you'll try to use strings or some other complex > structures it'll be less great :-/ In C++ it's done with "class's new" but I > know of no such mechanism in GPC ... At least low-level allocation functions > needed (now many bytes GC should allocate to put this structure there? how > really put it there?)... I haven't used it yet, but I don't see the problem. AFAIUI, Boehm's GC <http://reality.sgi.com/boehm/gc.html> provides a drop-in replacement for malloc() (and a dummy replacement for free()). Since GPC's memory management uses malloc()/free() by default (it can be overwritten on the Pascal level, but this doesn't seem necessary here), it should work, however simple or complex the structures (malloc() doesn't care, it just gets a number of bytes and allocates that much memory). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 5

Re: GC & GPC question.
by Frank Heckenbach 09 Mar '00

09 Mar '00

Khimenko Victor wrote: > Perhaps. If I'll be able to understood how to use GC at all (and no, NOT as > replacement for normal new/free functions!). As I've never used it so far, I can't tell you, but there must be a way to use it without replacing malloc/free. > P.S. If you are just replacing malloc with GC_alloc then you asking for > troubles (nasty DoS attacks). Depends on the kind of program, doesn't it? If it isn't a server (or run by one), the worst it could do is eat up memory and CPU time. But a malicious user who can run a program on a system can do this, anyway. Am I missing something? Of course, using GC_malloc_atomic can have its advantages, and you can use it with the hooks mentioned in my previous mail. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

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 March 2000