Gpc February 2002

gpc@gnu.de

42 participants
71 discussions

Re: gcc-3+
by da Silva, Joe 21 Feb '02

21 Feb '02

Frank is right. Just like you can't have "file" value parameters, you also can't have "store pointer" value parameters, only var parameters. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, February 21, 2002 12:31 AM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Markus Gerwinski wrote: > > > Frank Heckenbach wrote: > > > > > I don't understand. Passing a value parameter is almost the same > as > > > > > an assignment. I.e., if the procedure disposes of the store > pointer > > > > > parameter, the also store pointer in the caller gets invalid which > > > > > should not happen. > > > > Where did I say that? > > > Well, maybe you didn't say that, but I assumed the purpose was to > > > make pointer access safe. > > > > It is, but I don't see why the possibility of passing store pointers as > > parameters would make pointer access unsafe. So you would have the > > possibility of writing something like this: > > > > ... > > > > Procedure foo ( var sp: store pointer ); > > I said value parameter. So let's assume you meant: > > Procedure foo ( sp: store pointer ); > > > begin (* foo *) > > ... > > dispose ( sp ); > > ... > > end (* foo *); > > > > ... > > foo ( some_global_sp ); (* disposes of sp, thus setting all *) > > ... (* pointers referencing sp^ to nil. *) > > > > What's the problem here? > > During the execution of foo you have two store pointers of the same > thing, some_global_sp and sp. If this isn't a problem, then why > allow this only in this special case and not allow copying store > pointers in general? IOW, what's the difference why it's ok in this > case, but not in other cases? > > For the implementation it means that it would not only have to keep > track of all reference pointers, but also of all the store pointers. > I.e., if foo disposes of sp, it would also have to set > some_global_sp to nil (and possibly other instances of this store > pointer in other active routines as well), therefore it must be able > to find them because sp and some_global_sp are not the same variable > (since we're talking about value, not var, parameters). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: GNU Pascal web site
by da Silva, Joe 21 Feb '02

21 Feb '02

Maybe just change the copyright notice from "-2001" to "-2002"? <G> While I generally agree the word "last" can sometimes imply a finality, in this particular context this is a weak implication. OTOH, the word "latest" has the implication of something recent, whereas I understand that gpc-2.0 is actually very outdated, so using the word "latest" would encourage people to think of using gpc-2.0, contrary to the what that sentence is actually trying to say. Well, the imminent (?) release of gpc-2.1 should change any perception that this project may be dead, and hopefully the web site update at that time will address your concerns. Joe. > -----Original Message----- > From: strobe anarkhos [SMTP:anarkhos@mac.com] > Sent: Thursday, February 21, 2002 9:31 AM > To: gpc(a)gnu.de > Subject: GNU Pascal web site > > Is it just be or does the web site look dead. It's almost begging for a > huge declaration "THIS PROJECT ISN'T DEAD!!" > > I don't think the language used helps much. For example does the statement > "We already can recommend using it instead of gpc-2.0, the last official > release." imply 2.0 is the last official release, or the latest official > release? > > It also makes you go through several web pages if you want to get a FAQ or > status report. The GNUStep web site is a lot better. > > Anyway, I'm not complaining, just an observation |-\

1 0

GNU Pascal web site
by strobe anarkhos 20 Feb '02

20 Feb '02

Is it just be or does the web site look dead. It's almost begging for a huge declaration "THIS PROJECT ISN'T DEAD!!" I don't think the language used helps much. For example does the statement "We already can recommend using it instead of gpc-2.0, the last official release." imply 2.0 is the last official release, or the latest official release? It also makes you go through several web pages if you want to get a FAQ or status report. The GNUStep web site is a lot better. Anyway, I'm not complaining, just an observation |-\

1 0

Re: gcc-3+
by da Silva, Joe 20 Feb '02

20 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 18, 2002 8:27 AM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Markus Gerwinski wrote: > > > Frank Heckenbach wrote: > > > Though I'm not sure why the distinction between store and reference > > > pointers is necessary. Why not make all pointers the same, and when > > > one pointer to an object is disposed of, all the other ones are > > > invalidated? > > > > This is usually not, what you do... is it? If the pointer p1 is the one > used > > to allocate p1^, and it is also referenced by p2..pn, you normally take > care > > to use p1 again to deallocate, don't you? > > I don't think so. It's not uncommon, e.g., for a function to > allocate and return (copy) something in a pointer, or to pass (copy) > a pointer to a procedure to clean it up and dispose it. Or to > allocate a pointer in a local variable, do something with it, then > put it in a global list from where it's later disposed, etc. > > Or do you have any arguments why these are less common situations > than what you describe? > > > > > > Besides, when you really want to evaluate things, you have to > > > > > describe all the hidden costs first. AFAICS, for every object you > > > > > need an implicit list containing all the reference pointers, so > they > > > > > can be invalidated later. > > > > Depends on the way how to implement it... > > > Now I'm interested how else you'd implement it. An alternative I > > > could think of are double-pointers, but these are slower to > > > dereference and cause another kind of memory leak: Each second-level > > > pointer allocated once can never be freed if you don't know if > > > there's somewhere a first-level pointer pointing to it. I suppose > > > that's not what you have it mind. > > > > To be honest, I don't quite get the idea nor the problem... What exactly > do > > you mean by double-pointers? > > The problem is, as Marco said, how do you find all the existing > reference pointers to invalidate when disposing of one store > pointer. > > With double pointers I mean: When you allocate some memory, you > allocate another pointer to it, and let the real pointers point to > that. So if you dispose of the memory, you set the other pointer to > nil (or something), and you don't have to iterate over all reference > pointers. The problem then would be that you can never dispose of > the other pointer if you don't keep track of all existing reference > pointers, so it's not a good solution. > > Or how do you implement it? > [Joe da Silva] FWIW, I see the "store pointer" being what you are describing here as the "other pointer" (I think). It points to the real data, and the "reference pointers" just point to it (the "store pointer"). Since you are not allowed to "re-new" a "store pointer" without "disposing" first, the "reference pointers" can't become "stale". I'm not sure that affects how you keep track of the "reference pointers" though, you probably still need to point back at them as you suggest ("double pointers"), since searching for them would generally be inefficient. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 7

Re: pointers (was: gcc-3+)
by da Silva, Joe 20 Feb '02

20 Feb '02

Yes. Linked lists are both possible and easy, with your "store" and "reference" pointer idea, provided there is a standard (ie. inbuilt) "procedure" to swap two "store" pointers. I think that's all you need to overcome the problem with linked lists. Also, note that if either or both "store" pointers has any "reference" pointers associated with it, these "reference" pointers must still point at the same objects after the "store" pointer swap, as they did prior to the swap. Finally, some suggestions on nomenclature and syntax ... 1. I wonder if the words "store" and "reference" are complementary? How about "primary" and "secondary" instead? Or something else? This is subjective, but I'm not sure if the word "store" would "read" very well in the following suggested syntax (looks too much like a verb;-) : 2. Syntax suggestion : Type pointer1 = ^integer; {a standard pointer} pointer2 = primary ^integer; {a "store" pointer} pointer3 = secondary ^integer; {a "reference" pointer} Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Wednesday, February 20, 2002 2:53 AM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: pointers (was: gcc-3+) > > Hi folks, > > da Silva, Joe wrote: > > All you need is a standard (ie. inbuilt) procedure/statement > > that can swap two store pointers ... I think. > > You mean, for linked lists? > > Bye > > Markus

4 5

Re: pointers (was: gcc-3+)
by Markus Gerwinski 20 Feb '02

20 Feb '02

Hi folks, da Silva, Joe wrote: > No, the last statement cannot result in a new assignment > for the reference pointer. That's just unacceptable. That's > why Frank was saying you needed "double pointers", so > that you could specifically set the reference pointer to "nil" > when you disposed it's corresponding store pointer. Exactly. The other method would be fatal. > You could also search the reference pointers when > disposing a store pointer, to find out which of these are > affected, but that would be inefficient (like GC;-). But it's done in several languages -- e.g. for interfaces in Delphi. There you don't have an explicit store pointer, but a reference counter keeps track on every piece of memory; if the number of pointers referencing it decreases to 0, it is automatically disposed of. This requires exactly what you say: Searching for all references to a piece of memory, whenever a pointer is set away from it. Bye Markus

2 2

Re: pointers (was: gcc-3+)
by da Silva, Joe 20 Feb '02

20 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, February 20, 2002 12:03 PM > To: gpc(a)gnu.de > Subject: Re: pointers (was: gcc-3+) > > da Silva, Joe wrote: > > > Yes. Linked lists are both possible and easy, with your "store" and > > "reference" pointer idea, provided there is a standard (ie. inbuilt) > > "procedure" to swap two "store" pointers. I think that's all you need > > to overcome the problem with linked lists. > > Sorry, but to me it seems a way to solve this particular situation > that occurs with simple linked lists (as you described in a previous > mail) where you have an exact overview what is going on (and > therefore don't need the whole concept at all -- *because* you know > exactly what's going on, and could just do things correctly with > normal pointers). Avoiding memory leaks with simple links lists is > not exactly a difficult problem. > [Joe da Silva] True, standard pointers are quite adequate for simple linked lists. ------ snip ------

1 0

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

Hmmm ... This may not be as bad as it appears. All you need is a standard (ie. inbuilt) procedure/statement that can swap two store pointers ... I think. Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Tuesday, February 19, 2002 5:26 AM > To: Maurice Lombardi > Cc: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Hi folks, > > Maurice Lombardi wrote: > > Gosh. How do you do with linked lists, a quite common situation I > believe. > > If you append records only at the end of the list, you can use the last > "next" > > pointer as a store pointer. But what do you do if you want to insert a > new > > record in the middle of the list. Usually either: > > you keep the address of the next record in a temporary pointer and > allocate > > the new record with the "next" pointer of the previous: invalid because > you > > try to new an undisposed pointer. > > you allocate the new record with a "temporary" pointer (no problem up to > that > > point, it will be a store pointer) and then insert it, playing with two > "next" > > pointers: but the previous "next" goes from store to reference status. > And you > > need to keep somewhere all "temporary" pointers which served you to > allocate > > the elements ... > > Hmm, right. Here you got me. For linked-list maintenance etc., we need the > free play with pointers. (Awkward... I missed the trivial case by modeling > the complex ones...) > > Bye > > Markus

2 1

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

You take things too seriously, Frank. The wink in reference to GC was a clue that you shouldn't have ... <G> One of the key advantages of Pascal over more primitive languages, and one of several reasons it is much less bug prone, is that it imposes discipline on the program. IMHO, GC is contrary to that philosophy and not appropriate to Pascal (which is what we are discussing, since we have already established that the GPC compiler needs to use GC to be compatible with GCC-3). What I was thinking (in the previous message), was that if "double pointers" were not employed for this "store" and "reference" pointer suggestion, then it would be necessary to search the "reference" pointers to find which ones were no longer valid. And I was also thinking that GC must also do similar searching of pointers, but instead to find what memory blocks were no longer in use. So I reasoned that although searching the "reference" pointers would be relatively inefficient (compared to using "double pointers"), it should be comparable to GC, so I was merely putting this in perspective. While on this topic (you'll note that I had changed the subject heading, since we really aren't talking about the original GCC-3 issue any more), I had a thought that perhaps rather than setting any "reference" pointers to nil when their corresponding "store" pointer was disposed, perhaps this should really result in a run-time error. That is, you cannot dispose a "store" pointer if it has any "reference" pointers associated with it. This would be better than later in the code, trying to dereference a "reference" pointer, then trying to figure out why/when it became invalid. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, February 19, 2002 6:06 PM > To: gpc(a)gnu.de > Subject: Re: pointers (was: gcc-3+) > > da Silva, Joe wrote: > > > You could also search the reference pointers when > > disposing a store pointer, to find out which of these are > > affected, but that would be inefficient (like GC;-). > > It's always easy to make such claims, but I've yet to see a solution > (for the general case) that is more efficient, considering any > hidden costs? > > BTW, have you studied GC algorithms? I haven't, but I've see that > some research has done in this area and a good GC algorithm is quite > a bit better than an implementation I'd come up with if I tried it > naively ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Compiling inline assembly code
by Anuradha 19 Feb '02

19 Feb '02

Hello , The code probably doesnt use system calls-i am not sure. But there are some asm units that could take some time if we try to rewrite them in pascal. I am attaching one such code. Thanks and Regards, Anuradha PAGE 58,132 TITLE Compare routine PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Following EQU has to be set to 0 for NEAR call {$L compress.obj} ³ ;³ 1 for FAR call {INTERFACE in unit} ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; @_NEAR_FAR EQU 1 ; ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Return codes for compare ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; @C_RC_1G2 EQU -1 ; Return code first parameter greater @C_RC_1S2 EQU 1 ; Return code first parameter smaller @C_RC_1E2 EQU 0 ; Return code parameters equal PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Do not change following equates ³ ;³ Internals and parameter definitions ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; ; ; Pascal parameter offsets on stack ; @P_RET_ADD EQU 2*(@_NEAR_FAR+1) ; Size of the return address @P_SOURCE1 EQU [BP+@P_RET_ADD+14] ; Address of structure1 @P_OFFSET1 EQU [BP+@P_RET_ADD+12] ; Offset in structure1 @P_SOURCE2 EQU [BP+@P_RET_ADD+8] ; Address of structure2 @P_OFFSET2 EQU [BP+@P_RET_ADD+6] ; Offset in structure2 @P_LENGTH EQU [BP+@P_RET_ADD+4] ; Length to compare PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Compare routine : ³ ;³ Definition in Pascal : ³ ;³ FUNCTION COMPARE( VAR structure 1 ; ³ ;³ offset in structure 1 : INTEGER ; ³ ;³ VAR structure 2 ; ³ ;³ offset in structure 2 : INTEGER ; ³ ;³ length to compare : WORD ) : INTEGER ; ³ ;³ Return codes : ³ ;³ See equates above. ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; CODE SEGMENT BYTE PUBLIC 'CODE' ASSUME CS:CODE ; COMPARE PROC NEAR ; PUSH DS ; Save Pascal environment and PUSH BP ; get parameter addressablitity MOV BP,SP PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Set source and target address for compare. ³ ;³ Initialize compare counter. ³ ;³ Do the compare ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; COMP_000: LDS SI,@P_SOURCE1 ; DS:SI to structure 1 ADD SI,@P_OFFSET1 LES DI,@P_SOURCE2 ; ES:DI to structure 2 ADD DI,@P_OFFSET2 MOV CX,@P_LENGTH ; Compare counter JCXZ COMP_001 ; If nothing to compare then equal CLD REPE CMPSB ; Do the compare JE COMP_001 JB COMP_002 MOV AX,@C_RC_1G2 ; Return 1 greater than 2 JMP SHORT COMP_EX COMP_001: MOV AX,@C_RC_1E2 ; Return 1 equal 2 JMP SHORT COMP_EX COMP_002: MOV AX,@C_RC_1S2 ; Return 1 smaller than 2 PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Return point : restore Pascal environment and remove parameters. ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; COMP_EX: MOV SP,BP ; Delete local scratch path POP BP ; Restore Pascal environment POP DS IF @_NEAR_FAR RETF 14 ; Kill parameters and return ELSE RETN 14 ; Kill parameters and return ENDIF ; COMPARE ENDP ; CODE ENDS ; PUBLIC COMPARE ; END

2 1

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 February 2002