- Gambit-list - mailman.iro.umontreal.ca

Need MacGambit-C 3.0
by Frank Gizinski 09 Avr '06

09 Avr '06

To Whom it may concern, I had a hard disk failure. Wasn't backed up because I didn't have anything to back it up with. Recovered almost everything I had except MacGambit-C 3.0. Does anyone have a copy I can download or know where I can find one? Tried Google but couldn't find one there. Frank Gizinski

1 0

Clumsy reference to closure variable
by Bradley Lucier 09 Avr '06

09 Avr '06

I don't know if this is important in practice, but ... In lib/_num.scm you have (define (advance-state!) (##declare (not interrupts-enabled)) (let* ((x10 (##flonum.- (##flonum.* 1403580.0 (##f64vector-ref state 1)) (##flonum.* 810728.0 (##f64vector-ref state 2)))) (y10 (##flonum.- x10 (##flonum.* (##flonum.floor (##flonum./ x10 (macro-m1- inexact))) (macro-m1-inexact)))) (x20 (##flonum.- (##flonum.* 527612.0 (##f64vector-ref state 3)) (##flonum.* 1370589.0 (##f64vector-ref state 5)))) (y20 (##flonum.- x20 (##flonum.* (##flonum.floor (##flonum./ x20 (macro-m2- inexact))) (macro-m2-inexact)))) (dx (##flonum.- y10 y20)) (dy (##flonum.- dx (##flonum.* (##flonum.floor (##flonum./ dx (macro-m1- inexact))) (macro-m1-inexact))))) (##f64vector-set! state 5 (##f64vector-ref state 4)) (##f64vector-set! state 4 (##f64vector-ref state 3)) (##f64vector-set! state 3 y20) (##f64vector-set! state 2 (##f64vector-ref state 1)) (##f64vector-set! state 1 (##f64vector-ref state 0)) (##f64vector-set! state 0 y10) (##f64vector-set! state 6 dy))) where state is declared in the surrounding lexical environment. This is compiled to the C code: ___DEF_GLBL(___L199__23__23_make_2d_random_2d_source_2d_mrg32k3a) ___SET_R2(___UNBOX(___R1)) ___SET_F64(___F64V1,___F64VECTORREF(___R2,___FIX(2L))) ___SET_F64(___F64V2,___F64MUL(810728.,___F64V1)) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V3,___F64VECTORREF(___R3,___FIX(1L))) ___SET_F64(___F64V4,___F64MUL(1403580.,___F64V3)) ___SET_F64(___F64V5,___F64SUB(___F64V4,___F64V2)) ___SET_F64(___F64V6,___F64DIV(___F64V5,4294967087.)) ___SET_F64(___F64V7,___F64FLOOR(___F64V6)) ___SET_F64(___F64V8,___F64MUL(___F64V7,4294967087.)) ___SET_F64(___F64V9,___F64SUB(___F64V5,___F64V8)) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V10,___F64VECTORREF(___R3,___FIX(5L))) ___SET_F64(___F64V11,___F64MUL(1370589.,___F64V10)) ___SET_R4(___UNBOX(___R1)) ___SET_F64(___F64V12,___F64VECTORREF(___R4,___FIX(3L))) ___SET_F64(___F64V13,___F64MUL(527612.,___F64V12)) ___SET_F64(___F64V14,___F64SUB(___F64V13,___F64V11)) ___SET_F64(___F64V15,___F64DIV(___F64V14,4294944443.)) ___SET_F64(___F64V16,___F64FLOOR(___F64V15)) ___SET_F64(___F64V17,___F64MUL(___F64V16,4294944443.)) ___SET_F64(___F64V18,___F64SUB(___F64V14,___F64V17)) ___SET_F64(___F64V19,___F64SUB(___F64V9,___F64V18)) ___SET_F64(___F64V20,___F64DIV(___F64V19,4294967087.)) ___SET_F64(___F64V21,___F64FLOOR(___F64V20)) ___SET_F64(___F64V22,___F64MUL(___F64V21,4294967087.)) ___SET_F64(___F64V23,___F64SUB(___F64V19,___F64V22)) ___SET_STK(1,___UNBOX(___R1)) ___SET_F64(___F64V24,___F64VECTORREF(___STK(1),___FIX(4L))) ___SET_STK(2,___UNBOX(___R1)) ___F64VECTORSET(___STK(2),___FIX(5L),___F64V24) ___SET_STK(1,___UNBOX(___R1)) ___SET_F64(___F64V25,___F64VECTORREF(___STK(1),___FIX(3L))) ___SET_STK(2,___UNBOX(___R1)) ___F64VECTORSET(___STK(2),___FIX(4L),___F64V25) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(3L),___F64V18) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V26,___F64VECTORREF(___R3,___FIX(1L))) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(2L),___F64V26) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V27,___F64VECTORREF(___R3,___FIX(0L))) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(1L),___F64V27) ___SET_R3(___UNBOX(___R1)) ___F64VECTORSET(___R3,___FIX(0L),___F64V9) ___SET_R1(___UNBOX(___R1)) ___F64VECTORSET(___R1,___FIX(6L),___F64V23) ___JUMPPRM(___NOTHING,___R0) Note how state is continually unboxed into new registers and stack entries. If I change the argument list to (define (advance-state! state) <etc> and update all callers, the new code is ___DEF_GLBL(___L199__23__23_make_2d_random_2d_source_2d_mrg32k3a) ___SET_F64(___F64V1,___F64VECTORREF(___R1,___FIX(2L))) ___SET_F64(___F64V2,___F64MUL(810728.,___F64V1)) ___SET_F64(___F64V3,___F64VECTORREF(___R1,___FIX(1L))) ___SET_F64(___F64V4,___F64MUL(1403580.,___F64V3)) ___SET_F64(___F64V5,___F64SUB(___F64V4,___F64V2)) ___SET_F64(___F64V6,___F64DIV(___F64V5,4294967087.)) ___SET_F64(___F64V7,___F64FLOOR(___F64V6)) ___SET_F64(___F64V8,___F64MUL(___F64V7,4294967087.)) ___SET_F64(___F64V9,___F64SUB(___F64V5,___F64V8)) ___SET_F64(___F64V10,___F64VECTORREF(___R1,___FIX(5L))) ___SET_F64(___F64V11,___F64MUL(1370589.,___F64V10)) ___SET_F64(___F64V12,___F64VECTORREF(___R1,___FIX(3L))) ___SET_F64(___F64V13,___F64MUL(527612.,___F64V12)) ___SET_F64(___F64V14,___F64SUB(___F64V13,___F64V11)) ___SET_F64(___F64V15,___F64DIV(___F64V14,4294944443.)) ___SET_F64(___F64V16,___F64FLOOR(___F64V15)) ___SET_F64(___F64V17,___F64MUL(___F64V16,4294944443.)) ___SET_F64(___F64V18,___F64SUB(___F64V14,___F64V17)) ___SET_F64(___F64V19,___F64SUB(___F64V9,___F64V18)) ___SET_F64(___F64V20,___F64DIV(___F64V19,4294967087.)) ___SET_F64(___F64V21,___F64FLOOR(___F64V20)) ___SET_F64(___F64V22,___F64MUL(___F64V21,4294967087.)) ___SET_F64(___F64V23,___F64SUB(___F64V19,___F64V22)) ___SET_F64(___F64V24,___F64VECTORREF(___R1,___FIX(4L))) ___F64VECTORSET(___R1,___FIX(5L),___F64V24) ___SET_F64(___F64V25,___F64VECTORREF(___R1,___FIX(3L))) ___F64VECTORSET(___R1,___FIX(4L),___F64V25) ___F64VECTORSET(___R1,___FIX(3L),___F64V18) ___SET_F64(___F64V26,___F64VECTORREF(___R1,___FIX(1L))) ___F64VECTORSET(___R1,___FIX(2L),___F64V26) ___SET_F64(___F64V27,___F64VECTORREF(___R1,___FIX(0L))) ___F64VECTORSET(___R1,___FIX(1L),___F64V27) ___F64VECTORSET(___R1,___FIX(0L),___F64V9) ___F64VECTORSET(___R1,___FIX(6L),___F64V23) ___JUMPPRM(___NOTHING,___R0) Benchmarking shows that in this case it makes little difference (about 10%), perhaps because of the overhead of the glue surrounding the random-number generator. Before the change, simple fixnum loops (the number of iterations is the parameter) take: > (time (test-integers 1000000)) (time (test-integers 1000000)) 230 ms real time 230 ms cpu time (230 user, 0 system) no collections -16 bytes allocated 2 minor faults no major faults 81 > (time (test-integers 1000000)) (time (test-integers 1000000)) 231 ms real time 231 ms cpu time (231 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 67 > (time (test-reals 1000000)) (time (test-reals 1000000)) 220 ms real time 219 ms cpu time (210 user, 9 system) no collections 32000016 bytes allocated 3907 minor faults no major faults .6123283969620956 > (time (test-reals 1000000)) (time (test-reals 1000000)) 221 ms real time 221 ms cpu time (209 user, 12 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .7141848196160148 after: > (time (test-integers 1000000)) (time (test-integers 1000000)) 206 ms real time 205 ms cpu time (205 user, 0 system) no collections -16 bytes allocated 3 minor faults no major faults 81 > (time (test-integers 1000000)) (time (test-integers 1000000)) 203 ms real time 203 ms cpu time (203 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 67 > (time (test-reals 1000000)) (time (test-reals 1000000)) 197 ms real time 197 ms cpu time (187 user, 10 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .6123283969620956 > (time (test-reals 1000000)) (time (test-reals 1000000)) 203 ms real time 204 ms cpu time (189 user, 15 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .7141848196160148 while a loop that just makes calls to (values 0) through the trampoline takes: > (time (test-empty 1000000)) (time (test-empty 1000000)) 35 ms real time 35 ms cpu time (35 user, 0 system) no collections -16 bytes allocated no minor faults no major faults and a loop that does absolutely nothing except increment and test the loop variable takes > (time (test-really-empty 1000000)) (time (test-really-empty 1000000)) 1 ms real time 1 ms cpu time (1 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 0 It does make a significant difference in the code size: euler-42% ll `which gsc` -rwxr-xr-x 1 lucier pfaculty 7525990 Feb 2 00:57 /pkgs/Gambit-C/bin/ gsc* euler-43% ll gsc/gsc -rwxr-xr-x 1 lucier pfaculty 7464437 Apr 8 13:59 gsc/gsc* It would be nice if the compiler would just unbox the closure variable once and we wouldn't have to worry about this. Brad

1 0

Scheme Workshop 2006
by Robby Findler 05 Avr '06

05 Avr '06

Dear all, I'm writing to let you know about the upcoming Scheme and Functional Programming workshop -- specifically that the submission deadline is June 9, about 2 months from now. The workshop will be held Portland Oregon on September 17, the day before ICFP. We look forward you your submissions! Best, Robby ============================================================ The purpose of the workshop is to discuss experience with and future developments of the Scheme programming language, as well as general aspects of computer science loosely centered on the general theme of Scheme. http://scheme2006.cs.uchicago.edu/ IMPORTANT DATES Submission deadline: Friday June 9 Author notification: Friday June 30 Final versions due: Friday July 14 Workshop: Sunday September 17, the day before ICFP CALL FOR PAPERS Papers are invited concerning all aspects of the design, semantics, theory, application, implementation, and teaching of Scheme. Some example areas include (but are not limited to): * Language design Scheme's simple syntactic framework and minimal static semantics has historically made the language an attractive lab bench for the development and experimentation of novel language features and mechanisms. Topics in this area include modules systems, exceptions, control mechanisms, distributed programming, concurrency and synchronisation, macro systems, and objects. Past, present and future SRFIs are welcome. * Type systems Static analyses for dynamic type systems, type systems that bridge the gap between static and dynamic types, static systems with type dynamic extensions, weak typing. * Theory Formal semantics, calculi, correctness of analyses and transformations, lambda calculus. * Implementation Compilers, runtime systems, optimisation, virtual machines, resource management, interpreters, foreign-function and operating system interfaces, partial evaluation, program analysis and transformation, embedded systems, and generally implementations with novel or noteworthy features. * Program-development environments and tools The Lisp and Scheme family of programming languages have traditionally been the source of innovative program-development environments. Authors working on these issues are encouraged to submit papers describing their technologies. Topics include profilers, tracers, debuggers, program understanding tools, performance and conformance test suites and tools. * Education Scheme has achieved widespread use as a tool for teaching computer science. Papers on the theory and practice of teaching with Scheme are invited. * Agile Methogologies Dynamic languages seem to share a symbiotic relationship with agile software development methodologies. In particular, the dynamic type checking of Scheme clearly benefits from test-driven development, but that same dynamic checking makes the software more easily adapted to changing requirements. * Applications and experience Interesting applications which illuminate aspects of Scheme experience with Scheme in commercial or real-world contexts; use of Scheme as an extension or scripting language. * Scheme pearls Elegant, instructive examples of functional programming. A Scheme pearl submission is a special category, and should be a short paper presenting an algorithm, idea or programming device using Scheme in a way that is particularly elegant. Following the model of earlier workshops, experience papers need not necessarily report original research results; they may instead report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! ORGANIZERS Program Chair Robby Findler, University of Chicago Program Committee John Clements, Cal Poly Sebastian Egner, Philips Research Robby Findler, University of Chicago Cormac Flanagan, UC Santa Cruz Erik Hilsdale, Google Eric Knauel, University of Tubingen Steering Committee William D. Clinger, Northeastern University Marc Feeley, University of Montreal Robby Findler, University of Chicago Dan Friedman, Indiana University Christian Queinnec, University Paris 6 Manuel Serrano, INRIA Olin Shivers, Georgia Tech Mitchell Wand, Northeastern University

1 0

"make clean; make" doesn't work with --enable-shared on MacOS X
by Bradley Lucier 05 Avr '06

05 Avr '06

It rebuilds the dynamic library in lib, then in gsi you get DYLD_LIBRARY_PATH=../lib:/sw/lib:/pkgs/gcc-4.1.0/lib:/usr/local/ Gambit-C/lib/:/sw/lib ../gsc/gsc -:=".." -f -c -check _gsi.scm make[1]: *** [_gsi.c] Illegal instruction The problem is, you're trying to execute the old gsc, which depends on the old libgambc.dylib, with the recently-built libgambc.dylib. Perhaps we just need a "Don't do that" message in the documentation. Brad

1 0

More inlining notes
by Bradley Lucier 25 Mar '06

25 Mar '06

Marc: It would help a lot of the inliner knew more about the ##fixnum.blah? operators, e.g., that (##fixnum.+? x 0) == (##fixnum.+? 0 x) == x (##fixnum.-? x 0) == x (##fixnum.*? x 1) == (##fixnum.*? 1 x) == x (##fixnum.*? x 0) == (##fixnum.*? 0 x) == 0 (##fixnum.quotient x 1) == x (##fixnum.remainder x 1) == 0 (##fixnum.modulo x 1) == 0 I'm including example code and the expansion at the end of this e-mail. I'm thinking more and more that OPTIMIZE_SPACE should be defined by default in the .c file if any of the mostly-* declarations are in effect; there are just too many damn function calls generated with these options. Or maybe that it should just be defined by default unless a -optimize-space option is passed to gsc. Brad [lindv2:Arrays/srfi3/gsc-test] lucier% cat test.scm (define (a x) (- x 0)) (define (b x) (+ x 0)) (define (c x) (+ 0 x)) (define (d x) (* 1 x)) (define (e x) (* 0 x)) (define (f x) (quotient x 1)) (define (g x) (remainder x 1)) [lindv2:Arrays/srfi3/gsc-test] lucier% gsc -c -expansion test.scm Expansion: (define a:2 (lambda (x:3) (if (and (##eq?:4 -:5 '#<procedure #9 ->) (##fixnum?:6 x:3)) (let ((temp.2:7 (##fixnum.-?:8 x:3 0))) (if temp.2:7 temp. 2:7 (-:5 x:3 0))) (-:5 x:3 0)))) (define b:10 (lambda (x:11) (if (and (##eq?:4 +:12 '#<procedure #15 +>) (##fixnum?:6 x:11)) (let ((temp.5:13 (##fixnum.+?:14 x:11 0))) (if temp.5:13 temp.5:13 (+:12 x:11 0))) (+:12 x:11 0)))) (define c:16 (lambda (x:17) (if (and (##eq?:4 +:12 '#<procedure #15 +>) (and (##fixnum?:6 x: 17) #t)) (let ((temp.8:18 (##fixnum.+?:14 0 x:17))) (if temp.8:18 temp.8:18 (+:12 0 x:17))) (+:12 0 x:17)))) (define d:19 (lambda (x:20) (if (and (##eq?:4 *:21 '#<procedure #25 *>) (and (##fixnum?:6 x: 20) #t)) (if (##eqv?:22 x:20 0) 0 (let ((temp.11:23 (if (##eqv?:22 x:20 -1) -1 (##fixnum.*?:24 1 x:20)))) (if temp.11:23 temp.11:23 (*:21 1 x:20)))) (*:21 1 x:20)))) (define e:26 (lambda (x:27) (if (and (##eq?:4 *:21 '#<procedure #25 *>) (and (##fixnum?:6 x: 27) #t)) (if (##eqv?:22 x:27 0) 0 (let ((temp.14:28 (if (##eqv?:22 x:27 -1) 0 (##fixnum.*?: 24 0 x:27)))) (if temp.14:28 temp.14:28 (*:21 0 x:27)))) (*:21 0 x:27)))) (define f:29 (lambda (x:30) (if (and (##eq?:4 quotient:31 '#<procedure #33 quotient>) (and (##fixnum?:6 x:30) #t)) (##fixnum.quotient:32 x:30 1) (quotient:31 x:30 1)))) (define g:34 (lambda (x:35) (if (and (##eq?:4 remainder:36 '#<procedure #38 remainder>) (and (##fixnum?:6 x:35) #t)) (##fixnum.remainder:37 x:35 1) (remainder:36 x:35 1))))

1 1

(declare (mostly-fixnum)) vs (declare (mostly-fixnum-flonum))
by Bradley Lucier 23 Mar '06

23 Mar '06

Marc: I compiled an image processing application with mostly-fixnum and mostly-fixnum-flonum and here is what I found: [lindv2:Arrays/srfi3/gsc-test] lucier% ll total 107960 -rw-r--r-- 1 lucier lucier 4103052 Mar 21 15:51 all.c.fixnum -rw-r--r-- 1 lucier lucier 5489576 Mar 22 21:15 all.c.fixnum-flonum -rw-r--r-- 1 lucier lucier 6556015 Mar 22 20:28 all.i.fixnum -rw-r--r-- 1 lucier lucier 8689958 Mar 22 21:15 all.i.fixnum-flonum -rw-r--r-- 1 lucier lucier 1811056 Mar 22 20:45 all.o.fixnum -rw-r--r-- 1 lucier lucier 2492112 Mar 22 21:45 all.o.fixnum-flonum -rwxr-xr-x 1 lucier lucier 1449209 Mar 22 20:46 all.o1.fixnum* -rwxr-xr-x 1 lucier lucier 2029916 Mar 22 21:45 all.o1.fixnum- flonum* -rw-r--r-- 1 lucier lucier 5280685 Mar 22 20:45 all.s.fixnum -rw-r--r-- 1 lucier lucier 7388908 Mar 22 21:45 all.s.fixnum-flonum -rw-r--r-- 1 lucier lucier 558 Mar 22 21:15 all.scm -rw-r--r-- 1 lucier lucier 1631997 Mar 22 22:01 fixnum-expansion.scm -rw-r--r-- 1 lucier lucier 2151785 Mar 22 21:49 fixnum-flonum- expansion.scm -rwxr--r-- 1 lucier lucier 371 Mar 21 15:43 gaussian-random.scm* -rwxr--r-- 1 lucier lucier 88397 Mar 21 15:45 generic-arrays.scm* -rwxr--r-- 1 lucier lucier 25985 Mar 21 15:46 multi-calculus.scm* -rw-r--r-- 1 lucier lucier 6683 Mar 21 15:48 pgm.scm -rwxr--r-- 1 lucier lucier 9778 Mar 21 15:43 pixel-method.scm* -rwxr--r-- 1 lucier lucier 7113 Mar 21 15:46 point.scm* You can see the size of the .scm files, the .c files, the .i files after macro expansion, the .s files, etc. On a 2GHz Mac G5, the mostly-fixnum version took 2.4GB and 17 minutes to compile and the mostly-fixnum-flonum version took 3.4GB and 30 minutes to compile. This was with gcc-4.1.0 and not the compiler that apple ships (since the compiler that apple ships is 32-bit and can't allocate over 2.0 GB ;-). The mostly-fixnum-flonum code is not as big as one might expect, for the following reasons: 1. If you have (+ i 1), then because 1 is not a flonum, it doesn't generate the tests or the code for flonum.+. 2. Comparisons are relatively simple, e.g., (< x y) just adds "check whether x and y are flonums and compare them" to the code, no boxing, etc. So I don't see mostly-flonum-fixnum as that much of an added burden over mostly-fixnum. Brad

1 0

Inline make-vector and friends
by Bradley Lucier 23 Mar '06

23 Mar '06

Marc: You can also inline (make-vector n) and (make-vector n x) (and friends) when n is a known small nonnegative fixnum. I see things like this in manipulation of small geometric vectors. Brad

1 0

More inlinable routines
by Bradley Lucier 22 Mar '06

22 Mar '06

Marc: I decided to go through gambit.h in a somewhat regular way to see which functions are inlined and which could be inlined in gambc40b17. I know your current source tree inlines more, so I apologize if some of these are already done, but here are things that I found could be inlined. This is copied from an expansion of test code. 1. With mostly-fixnum: (bitwise-ior:80 x:57 y:58) (bitwise-xor:81 x:57 y:58) (bitwise-and:82 x:57 y:58) (bitwise-not:83 x:57) (arithmetic-shift:84 x:57 -2) (zero?:85 x:57) (negative?:86 x:57) (positive?:87 x:57) (odd?:88 x:57) (even?:89 x:57) (exact->inexact:99) (max:100 x:57 y:58) (min:101 x:57 y:58) (abs:103 x:57) (floor:104 x:57) (ceiling:105 x:57) (round:106 x:57) (set-car!:123 x:57 y:58) (set-cdr!:124 x:57 y:58) (vector-length:138 x:57) (vector-ref:139 x:57 y:58) (vector-set!:140 x:57 y:58 z:59) (string-length:141 x:57) (string-ref:142 x:57 y:58) (string-set!:143 x:57 y:58 z:59) (s8vector-length:144 x:57) (s8vector-ref:145 x:57 y:58) (s8vector-set!:146 x:57 y:58 z:59) (s16vector-length:147 x:57) (s16vector-ref:148 x:57 y:58) (s16vector-set!:149 x:57 y:58 z:59) (s32vector-length:150 x:57) (s32vector-ref:151 x:57 y:58) (s32vector-set!:152 x:57 y:58 z:59) (s64vector-length:153 x:57) (s64vector-ref:154 x:57 y:58) (s64vector-set!:155 x:57 y:58 z:59) (u8vector-length:156 x:57) (u8vector-ref:157 x:57 y:58) (u8vector-set!:158 x:57 y:58 z:59) (u16vector-length:159 x:57) (u16vector-ref:160 x:57 y:58) (u16vector-set!:161 x:57 y:58 z:59) (u32vector-length:162 x:57) (u32vector-ref:163 x:57 y:58) (u32vector-set!:164 x:57 y:58 z:59) (u64vector-length:165 x:57) (u64vector-ref:166 x:57 y:58) (u64vector-set!:167 x:57 y:58 z:59) (f32vector-length:168 x:57) (f32vector-ref:169 x:57 y:58) (f32vector-set!:170 x:57 y:58 z:59) (f64vector-length:171 x:57) (f64vector-ref:172 x:57 y:58) (f64vector-set!:173 x:57 y:58 z:59)))) 2. With mostly-flonum: If x is a flonum, these should just return x; instead, they box a copy of x: (+ x) (* x) These actually generate incorrect code, returning (a copy of) flonum 0. and 1. instead of fixnum 0 and 1: (+) (*) Unimplemented: (zero?:85 x:205) (negative?:86 x:205) (positive?:87 x:205) This should just check if its argument is inexact, and return it if so: (exact->inexact:99) Unimplemented: (max:100 x:205 y:206) (min:101 x:205 y:206) (abs:103 x:205) (floor:104 x:205) (ceiling:105 x:205) (round:106 x:205) (exp:107 x:205) unimplemented (need care to check for range of arguments): (asin:112 x:205) (acos:113 x:205) (atan:114 x:205) (sqrt:116 x:205) Unimplemented: (atan:114 x:205 y:206)

1 0

readtables question; compiler expansion
by Christian 20 Mar '06

20 Mar '06

Hello The default printer uses an output format which uses #< > with the structure name and serial number, like: > values #<procedure #776 values> > Is there a way to read (or parse) that format back in? I've played with readtables but could not get |read| to understand it. I'm asking (this time) because I want to clean up the output of the 'expansion compiler option, so that it can be diff'ed (remove the :numbers from the symbols etc.). Or is there a better way printing the expansion (so that it doesn't contain those numbers in the first place)? Thanks Christian.

1 0

Re: [gambit-list] Gambit-C Debian 4.0.b17 Packages Available
by Bradley Lucier 16 Mar '06

16 Mar '06

On Mar 14, 2006, at 8:43 PM, Kurt B. Kaiser wrote: > The overall average memory use during compile is a lot higher. > > But it doesn't seem ridiculous, so I will add this config option. Sounds good. > >> If you wanted to reduce the resources needed to compile Gambit, you >> might be better off setting >> + #define ___OPTIMIZE_SPACE > > Can I assume that this macro is effective for all gsc compiles, not > just for the build of Gambit-C itself? Yes. > If the former, I'd be > reluctant to add it since most people have quite a bit of memory these > days. OK, sounds good. Brad

1 0