gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: CALL-ARGUMENTS-LIMIT and other things


From: Camm Maguire
Subject: [Gcl-devel] Re: CALL-ARGUMENTS-LIMIT and other things
Date: 02 Nov 2004 12:52:46 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> 1. While trawling through the ANSI tester output a few days ago I noticed
> that call-arguments-limit (set to 64) conflicts with the test in "eval.c"
> based on the C macro MAX_ARGS (63) defined in "h/funlink.h".
> 
> I played it safe and set call-arguments-limit to MAX_ARGS (in "eval.c")
> which I left at 63.  This fixed the failure of SUBTRACT.3 in the ANSI tests:
> 
> (LET ((ARGS NIL))
>         (LOOP
>           FOR
>           I
>           FROM
>           1
>           TO
>           (MIN 256 (1- CALL-ARGUMENTS-LIMIT))
>           DO
>           (PUSH 1 ARGS)
>           ALWAYS
>           (EQL (APPLY #'- 1000 ARGS) (- 1000 I))))
> 
> but is not necessarily a high quality design decision.  I also set
> LAMBDA-PARAMETERS-LIMIT to MAX_ARGS.
> 

Thanks for your changes here, discussed separately, which all look fine.

> Now in CVS.
> 
> 
> 2. Also now in CVS is stack size configuration for Windows.  I still need to
> link it to the test for C stack origin by passing a switch to the linker for
> that test.  It is possible that other platforms may be affected accidentally
> by these changes - hopefully not.
> 

Small error here breaking the Linux build.  Committed a fix.  Please
object if necessary. :-)

> 3. I am proposing a patch to GCL along the general lines set out below to
> remove compiler warnings about the unknown optimizer quality "debug" as
> frequently seen in the ANSI test output.  These changes (*debug* and
> appropriate checks in "cmpnew/gcl_cmpmain.lsp") are sufficient to remove
> those warnings but I've hesitated about an appropriate compiler response to
> the debug quality in light of the CLHS discussion:
> 
>   http://www.lispworks.com/reference/HyperSpec/Issues/iss251_w.htm
> 

I certainly agree, at least personally, with the paragraph at the
bottom here.  These compilation parameters are confusing.

That said, we could do some creative things here given that we mostly
build atop gcc.  *debug* should strip out -fomit-frame-pointer, turn
on *c-debug* aka. -g, turn on *default-c-file* and *keep-gaz*, and
push the file load address to the function symbol plist (as its lambda
list is done now) with the debug property, so that we might facilitate
running atop gdb and loading the symbol tables dynamically at runtime.

Not that it would do much, but *space* should throw -Os.  This does
conflict with *speed*, as does *debug* via the conflict with
-fomit-frame-pointer.  Other than this, debugging and speed are mostly
orthogonal with gcc.

To my very limited understanding, *safety* is effectively a binary
toggle, turning on type checking (alone) in the compiled code.

> I imagine that the right thing would be for that quality to put debug
> switches in the C compiler command line via *c-debug* , leaving manipulation
> of C optimizer switches to the other optimizer qualities (it might be
> beneficial, on occasion, to have maximum optimization with debug symbols).
> 
> The negative side to this patch is that I renamed "si::debug" to
> "si::debugger" to avoid a namespace clash with the compiler debug quality
> symbol.
> 
> Not yet in CVS
> 

I've seen your patch, and it looks good.  I don't see the name clash.
*debug*!=debug, no?  Currently, the symbol represents both a function
and denotes an element in a symbol's plist.  It would not appear that
this would have to be changed.  If it does need changing, we should
change the C vars sSdebug and fSdebug accordingly.

I'd like to work a bit on this too time permitting.

> After these changes 1164 of the ANSI tests fail on Windows.
> 

Great!

Most of this stuff, for me at least, is pretty printing.  Haven't yet
heard from anyone regarding the advisability of inhaling XP as
compared with rolling our own.

Take care,

> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]