Andreas Jaeger wrote:

Frank Heckenbach frank@g-n-u.de writes:

...

[..]

I'll try your suggestion.

...

So, you might want to try removing the statement, but I'm not sure if it will work yet. If gcc-3.2 supports this platform, I recommend to try this for now.

GCC 3.2 is available but I need GCC 3.3 for other purposes and will not go back to 3.2,

You can build GPC with a different GCC version than what you use as the C (or other languages) compiler. Other than that, I can only wish you good luck.

Frank

Andreas Jaeger wrote:

One more thing that does not seems to work are profile driven optimizations. Are you supporting -profile-arcs and -fbranch-probabilities?

We don't do anything special about them. Is this required, i.e., aren't they handled by the backend?

Frank

Frank Heckenbach Frank@G-N-U.De Writes:

Andreas Jaeger Wrote:

...

One More Thing That Does Not Seems To Work Are Profile Driven Optimizations. Are You Supporting -Profile-Arcs And -Fbranch-Probabilities?

We Don't Do Anything Special About Them. Is This Required, I.E., Aren't They Handled By The Backend?

Honza, can you explain what needs to be done?

AFAIK you do not initialize some fields correctly but Honza knows more...

Andreas

Waldek Hebisch wrote:

I just noticed that hammer backend can not pass Pascal sets as arguments to functions (procedures). The problem should be easy to solve, but first somebody must decide how sets should be treated on hammer. Currently frontend treats sets as a sequence of longs, that should work, but on hammer SSE2 instructions would double efficiency for moderate and large sets. So the question is if we should just teach backend about our current strategy or should we try something more fancy?

If someone wants to optimize things using these special instructions, that can always be done (though it might be quite some work, since probably all of the routines in rts/sets.pas and the corresponding compiler support will have to be rewritten).

However, as you say, the current mechanism treats them as arrays of unsigned long (in C terms), so it should also work. (There's not so much special about it.) I don't know how it fails, but it might be a more general problem.

Frank

Waldek Hebisch wrote:

My point was that we must make an API decision. Easy one is to stick to current scheme. Hard one is to try to use SSE2. SSE2 requires 128 bit alignment and means that when passing set to functions they should go in SSE register.

I infer that Frank prefers easy way

Unless someone volunteers to implement the hard one. (I won't stop them, but I won't write it myself.)

Frank

Waldek Hebisch wrote:

...

Unless someone volunteers to implement the hard one. (I won't stop them, but I won't write it myself.)

Jan Hubicka pointed out that membership testing is more expensive with SSE2, which means that hard way may in fact be slower. So I am too for easy way.

Though for set constructors, GPC optimizes membership tests and does not use sets internally at all (e.g. `x in [a .. b, c]' is turned to `((x >= a) and (x <= b)) or (x = c)' (taking care of side-effects in x). But this doesn't cover all uses of sets, and if it's not clear that it's a gain, it's probably not worth it.

Frank

Waldek Hebisch hebisch@math.uni.wroc.pl writes:

Andreas Jaeger wrote:

...

I'd like to have an integrated compiler.

...

the C (or other languages) compiler. Other than that, I can only wish you good luck.

Doesn't work unfortunatly. Ok, I'll wait some time and retry again.

There are three known problem with gcc-3.3+gpc-20030507:

-- spurious `free'. The first patch (hunk) below fixes it

-- problem with generating Dwarf-2 debug info. It not clear what the good solution is but the second patch is a workaround. Alternatively you may pass `PFLAGS=-gstubs+' to make build the runtime with stubs debug info (may be a good idea anyway, as gdb has serious troubles with Dwarf-2 debug info, in fact without patches gdb abort on Dwarf-2 info from Pascal).

Thanks, I wasn't aware of this one. Note that I really need dwarf2 since stubs are not 64-bit clean and cannot be used on x86-64 (AMD64).

-- problem building `gpidump' utility. The third patch fixes it

If there are another problems let us know

OK, will retry later with the dwarf2 patch,

Andreas

On Tue, Jun 24, 2003 at 07:52:44PM +0800, Peter N Lewis wrote:

In Metrowerks Pascal, there is a compiler "variable" that has the name of the source file (SrcFile, String) and the current line number (SrcLine, Integer), which can be quite useful for debugging.

Is there an equivalent in GPC?

GPC preprocessor provides magic "macros" __FILE__ and __LINE__.

Emil

Thanks, Peter.

-- http://www.interarchy.com/ http://documentation.interarchy.com/

Grant Jacobs wrote:

At 2:14 PM +0200 24/6/03, Emil Jerabek wrote:

...

On Tue, Jun 24, 2003 at 07:52:44PM +0800, Peter N Lewis wrote:

...

In Metrowerks Pascal, there is a compiler "variable" that has the name of the source file (SrcFile, String) and the current line number (SrcLine, Integer), which can be quite useful for debugging.

Is there an equivalent in GPC?

GPC preprocessor provides magic "macros" __FILE__ and __LINE__.

And also __func__ ? (As in C99...)

`CurrentRoutineName' (which is no macro, but a magic "function" yielding a string constant(!); this is because it's handled by the compiler, not the preprocessor, but for most purposes, it should appear mostly the same as a macro).

These are the three I use to build my C99 assert() function and some other tracing stuff.

It's not really necessary. GPC has a built-in `Assert' procedure which in case of failure gives a regular runtime error. Runtime errors contain the code position which can be converted to a source position using `addr2line'. Using the runtime option `--gpc-rts=-E' or `--gpc-rts=-F', you can also get a call trace in case of runtime error. The script `gpc-run' automatizes this.

Frank

At 12:59 PM +0800 25/6/03, Peter N Lewis wrote:

...

...

These are the three I use to build my C99 assert() function and some other tracing stuff.

It's not really necessary. GPC has a built-in `Assert' procedure which in case of failure gives a regular runtime error.

Yes, but my reading of this was that it could not be compiled out (turned off, but not compiled out), which is insufficient - it does not properly encourage asserting *everything* which (IMO, as well as Steve Maguire's, see Writing Solid Code which is a very good book (despite coming from Microsoft)). As much as possible I assert every precondition on entry and every post condition on exit to procedures, as well as asserting the validity of data structures and such. All this code is far too time consuming to leave in a shipping version.

Caveat: I haven't used assert in GPC - too busy on the day job... - so maybe I'm barking up the wrong tree...

I agree being able to strip out assert code makes them much more powerful.

In my C code I (try to!) do precisely what you do, using my own onEntry, onExit and assert macros. These macros can strip the code out later, so as you're saying you're encouraged to use them to the nth degree. All of this ties in with traces for automated testing, etc. Nice to see another fan of this sort of thing :-)

I understand why the Assert's in GPC are done that way, but it does not work for me in the way I use assertions.

Enjoy, Peter.

But I don't really understand the difference you make between turned off and compiled out. If assertions are turned off, no code is generated for them, unless they have side-effects, i.e. cases such as:

{ Returns True on success, False on failure. } function Foo (a: Integer): Boolean; [...]

Assert (Foo (42));

With assertions turned off, this is equivalent to:

Dummy := Foo (42);

(where Dummy is an otherwise unused Boolean variable).

That's the point. My assertions tend to be things like:

Assert( ValidDataStructure( x ) );

ValidDataStructure might be a very expensive call, it might parse through the entire data structure looking for holes in it.

This behaviour may be debatable. I think it would be more risky to discard side-effects as well (especially if most testing is done with assertions turned on).

But I'm not sure if that's actually what you're referring to.

Absolutely, it is definitely a case of tradeoffs. You have to be disciplined about your use of Asserts to ensure you never use any code in them that is required to be executed. It's all too easy to write things like:

Assert( OpenFile( f, name ) = noErr );

As I said, I fully understand why they are done the way they are done. However for me, the tradeoff with that is that it restricts the cases I would be willing to use Assert for. No one would want to write code like:

procedure AppendToList( var list: ListType; item: ItemType ); begin Assert( ValidList( list ) ); ...

if they new that in the production code their O(1) AppendToList function would actually be O(n) or worse.

It's a trade off of safety (in executing potentially side effect riddled code) with safety (in writing reliable well tested programs).

GPC also makes this more challenging because you can't define a macro in any given unit for asserting the validity of data structures because that macro is not propagated into the using units. For example, in the interface my hypothetical Lists unit above, I would add something like:

{$ifc not do_debug} {$definec AssertValidList( list )} {$elsec} {$definec AssertValidList( list ) AssertValidListCode( list, SrcFile, SrcLine )} {$endc}

{$ifc do_debug} procedure AssertValidListCode( list: ListType; source: String; line: Integer ); {$endc}

but that does not work in GPC. My solution has been to use a prefix file and copy all such macro definitions to the prefix file. This is less than ideal since it breaks the modularity. Perhaps someone has a better solution for me, but it's the best I can come up with so far.

BTW, I really really strongly recommend that all programs go and read Writing Solid Code.

Enjoy, Peter.

At 10:38 AM +0800 26/6/03, Peter N Lewis wrote:but that does not work in GPC. My solution has been to use a prefix file and copy all such macro definitions to the prefix file. This is less than ideal since it breaks the modularity. Perhaps someone has a better solution for me, but it's the best I can come up with so far.

Forgive me for a rambling a few thoughts on this.

I haven't time to test this, but how does it go if a procedure does no productive activity - does the compiler strip the procedure and its calls out? (i.e. detecting an empty procedure body.) Have a constant, something like:

const doAsserts = false ;

and somewhere in the code calling your own assert defined like:

procedure assert( ... ) begin if doAsserts then begin end end

Would the compiler recognise that the above procedure is useless (when doAsserts = true) and strip out the calls to new assert() procedure ?

(Of course you could also pass the state as a variable and we can all argue about use of globals, etc. In this case the compiler needs to recognise that the variable in fact has a constant value, etc.)

On the same lines you could have your assert() as a function yielding a constant value (false), which the compiler can strip out if it sees:

dummyVar = assert( something ) ;

Like Peter some of my asserts call very expensive functions, so stripping them out in production code is essential.

A possible compromise might be to have GPC continue as-is, but for Peter to put the if's into his testing routines, the ones called by GPCs' assert, e.g.:

Assert( ValidDataStructure( thingy ) );

with assertions off becomes:

DummyVar := ValidDataStructure( thingy ) ;

but ValidDataStructure() contains an 'if' on a constant, which causes the procedure body to be empty, which the compiler then strips... (or doesn't if it can't do this).

This won't cater for everything (for example an assertion on an expression), but it might be OK for the more expensive things since they are likely to be function calls anyway - ?

Just while I'm writing: over-and-above the usual '#if debug' type of thing, my C debugging/assert/etc. routines pass variables that have four-states for this and other forms of testing (always, never, onTrue and onFalse). Usually these are effectively and'ed with another variable, e.g. the result of the assert or a global control variable such as doAsserts. This way the caller has control over individual asserts.

Grant

Peter N Lewis wrote:

...

But I don't really understand the difference you make between turned off and compiled out. If assertions are turned off, no code is generated for them, unless they have side-effects, i.e. cases such as:

{ Returns True on success, False on failure. } function Foo (a: Integer): Boolean; [...]

Assert (Foo (42));

With assertions turned off, this is equivalent to:

Dummy := Foo (42);

(where Dummy is an otherwise unused Boolean variable).

That's the point. My assertions tend to be things like:

Assert( ValidDataStructure( x ) );

ValidDataStructure might be a very expensive call, it might parse through the entire data structure looking for holes in it.

...

This behaviour may be debatable. I think it would be more risky to discard side-effects as well (especially if most testing is done with assertions turned on).

But I'm not sure if that's actually what you're referring to.

Absolutely, it is definitely a case of tradeoffs. You have to be disciplined about your use of Asserts to ensure you never use any code in them that is required to be executed. It's all too easy to write things like:

Assert( OpenFile( f, name ) = noErr );

As I said, I fully understand why they are done the way they are done. However for me, the tradeoff with that is that it restricts the cases I would be willing to use Assert for. No one would want to write code like:

procedure AppendToList( var list: ListType; item: ItemType ); begin Assert( ValidList( list ) ); ...

if they new that in the production code their O(1) AppendToList function would actually be O(n) or worse.

It's a trade off of safety (in executing potentially side effect riddled code) with safety (in writing reliable well tested programs).

GPC also makes this more challenging because you can't define a macro in any given unit for asserting the validity of data structures because that macro is not propagated into the using units. For example, in the interface my hypothetical Lists unit above, I would add something like:

{$ifc not do_debug} {$definec AssertValidList( list )} {$elsec} {$definec AssertValidList( list ) AssertValidListCode( list, SrcFile, SrcLine )} {$endc}

{$ifc do_debug} procedure AssertValidListCode( list: ListType; source: String; line: Integer ); {$endc}

but that does not work in GPC. My solution has been to use a prefix file and copy all such macro definitions to the prefix file. This is less than ideal since it breaks the modularity. Perhaps someone has a better solution for me, but it's the best I can come up with so far.

Although it wouldn't be backward compatible with CW Pascal, you might want to look into using GPC's support for Extended Pascal's module multiple interface exports and export renaming. For example:

module MyLists;

export MyLists = (AppendToList); MyListsDebug = (AppendToListDebug => AppendToList); {insert const and type declarations needed for interface declarations} procedure AppendToList( var list: ListType; item: ItemType ); procedure AppendToListDebug( var list: ListType; item: ItemType ); end; {module heading}

function ValidList( protected var list: ListType): boolean; {insert list validation implementation code block}

procedure AppendToList( var list: ListType; item: ItemType ); {insert procedure's implementation code block}

procedure AppendToListDebug( var list: ListType; item: ItemType ); begin {pre-condition asserts go here} Assert( ValidList( list ) ); AppendToList( var list: ListType; item: ItemType ); {post-condition asserts go here} end; end. {module block}

Then in code using the MyLists module, use conditional compilation directives to select the debugging interface or the non-debugging interface. For example:

procedure DoSomethingWithLists; {$ifc not do_debug} import MyLists; {$elsec} import MyListsDebug in 'MyLists.pas'; {$endc} {insert other needed declarations} begin {...} {With do_debug = true, this ends up calling AppendToListDebug with the pre- and post-conditions assertion checks. Otherwise, it calls AppendToList which doesn't have the assertion overhead.} AppendToList(theList,anItem); end;

Then as long as you practice a discipline of side-effect free pre-condition and post-condition asserts, the effects of debugging/non-debugging versions will be transparent; will retain modularity; and will avoid the debugging code overhead in non-debug production code. If you're using a smart linker, the debugging code routines should also be dead stripped from the production executeable since the debugging related routines are never called from production code.