00:09:35 i hope nikodemus or so get's the docstring things up.....i would like to read the cl spec in info format right from texinfo files........ 00:11:23 having an info reader on keywords in climacs would be good too.... 00:51:48 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 01:43:55 Phoodus [~foo@68.107.217.139] has joined #sbcl 01:45:55 is sbcl's atan backwards from the clhs? seems sbcl is (atan y x) and clhs is (atan x y) to me 01:46:10 (((( 01:46:21 oops, sorry 01:47:20 Phoodus: it's just a name. 01:48:48 it seems easy and beneficial to rename arguments and avoid unnecessary surprises.. 01:48:48 ok, I just tested again, you're right. I thought I ran the numbers and it matched the names 01:55:21 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 01:57:02 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 05:37:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:41:13 tsuru` [~charlie@adsl-74-179-30-61.bna.bellsouth.net] has joined #sbcl 05:43:18 -!- tsuru [~charlie@adsl-98-87-48-164.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 05:51:15 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 05:51:39 -!- homie [~levgue@xdsl-78-35-184-223.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 06:25:59 -!- tsuru` [~charlie@adsl-74-179-30-61.bna.bellsouth.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 06:42:27 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 07:01:33 sdemarre [~serge@91.176.114.83] has joined #sbcl 07:47:16 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 08:12:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 08:26:37 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:34:36 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:37:18 good morning everyone 09:23:33 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:24:53 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:28:11 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 10:28:11 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 10:28:11 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:53:10 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:53:10 -!- ChanServ has set mode +o nikodemus 10:56:06 -!- sdemarre [~serge@91.176.114.83] has quit [Ping timeout: 240 seconds] 11:11:03 sdemarre [~serge@91.176.92.106] has joined #sbcl 11:23:00 -!- whoops [u549@gateway/web/irccloud.com/x-znnenajhocnrogzq] has quit [Ping timeout: 256 seconds] 11:37:03 whoops [u549@gateway/web/irccloud.com/x-imcngkgbzbtdsblr] has joined #sbcl 12:15:46 asynch interrupts. /hate/ 13:49:14 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 14:16:41 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:16:50 G'morning all. 14:19:10 hi nyef 14:40:30 -!- sdemarre [~serge@91.176.92.106] has quit [Ping timeout: 240 seconds] 14:54:36 sdemarre [~serge@91.176.92.106] has joined #sbcl 15:18:11 tsuru` [~charlie@adsl-74-179-30-61.bna.bellsouth.net] has joined #sbcl 15:24:50 Looking at SBCL 1.0.53 with its 63-bit fixnums. How does it work? Previous versions had three bits for tags. Does it now have a different number of tag bits depending on content? I.e. if the LSB is 0, then only that bit is that tag bit, otherwise the number of bits may be different? 15:25:01 it has always had that property 15:25:17 e.g. 32-bit sbcl has 2 tag bits for fixnums and 3 for everything else 15:25:23 Hmm 15:25:31 previously, 64-bit sbcl had 3 tag bits for fixnums and 4 for everything else 15:25:37 Where in the source code can I find a description of how the tag bits are used? 15:25:39 <|3b|> you could also interpret as having multiple tags for fixnums, which happen to match some bits of the fixnum value 15:25:55 |3b|: fair enough 15:26:06 Is there some place in the code where the tag bits are decoded that I can read? 15:26:08 but then nyef realised that we had a lot of spare tags and a rearrangement would allow fewer tags for fixnums 15:27:09 src/compiler/generic/{early-,}objdef.lisp 15:27:27 thanks 15:27:49 Figuring out and writing down the constraints on lowtag allocation was a bit of a pain. 15:29:18 Note that you can set n-fixnum-tag-bits in src/compiler/generic/early-vm.lisp to anything between 1 and 3 (inclusive) on 64-bit targets before you build SBCL, and you should end up with a working product. 15:29:20 reading the code now... what is "lowtag"? 15:29:35 the low N bits of what is morally a pointer (or "lispobj") 15:31:47 -!- akovalenko [~anton@77.51.3.36] has quit [Remote host closed the connection] 15:35:01 Oh, so heap objects have different types of tagging? The widetag? 15:35:33 The EncyCMUCLopedia has a file discussing in-memory representation for things. 15:35:50 (Under the "new type scheme", meaning lowtags instead of hightags.) 15:35:55 Does that mean that a fixnum stored on the heap, even if that fixnum is the value 1, will take 2*64 bits of storage? 15:37:41 Fixnums are lispobjs, so they are a single word. 15:37:58 not if it's an unboxed struct field, or an element of an appropriately-typed array. right? 15:38:18 and presumably unboxed closure vars also exist? 15:38:24 A CONS is not a lispobj, so it takes two words, both of which hold lispobjs, either of which can be a fixnum, point to a CONS, and so on. 15:38:36 I see 15:38:43 ... I don't know that we do unboxed heap-allocated value-cells. 15:39:29 if there is, it had better be allocated in pairs, since it'd look like a cons. :) 15:41:15 homie [~levgue@xdsl-78-35-177-149.netcologne.de] has joined #sbcl 15:42:08 foom: same as T cells: they need a header for the widetag. 15:44:14 akovalenko [~anton@77.51.3.36] has joined #sbcl 15:44:23 Oh! Hey, what about doc/internals/objects-in-memory.texinfo? Or the corresponding chapter in a built manual? 15:44:59 How is a value of MAX-POSITIVE-FIXNUM stored in the heap then? Exactly like the register content? 15:45:30 MOST-POSITIVE-FIXNUM? It's stored in the VALUE slot of a SYMBOL object. 15:45:46 most-positive-fixnum is still a fixnum.. 15:45:48 So yes, exactly like the register content. 15:47:11 nyef: is it always stored in the value-slot? If I do the following, where is the 10 stored? (let ((x 10)) (defun foo () x)) 15:47:48 (although I suppose that it could be inlined in that case...) 15:48:00 heap ? 15:48:04 Where is the value stored here: (let ((x 10)) (defun foo () (incf x))) 15:48:06 I would expect that to inline the constant, so it becomes an immediate move instruction. 15:48:20 nyef: Yeah, that's why I changed it to the second example. 15:48:20 That should allocate a value-cell. 15:49:06 The value cell is two words, the first of which has a particular widetag, the second of which is a LISPOBJ, which starts out as a FIXNUM but can end up being a pointer to a BIGNUM. 15:49:18 I see 15:49:34 so as long as it fits inside a fixnum, it'll take up 128 bits on the heap, yes? 15:49:43 (two words) 15:49:52 loke: it will always take up exactly two words. 15:49:59 One of the word may eventually be a pointer. 15:50:32 ah well. In the bignum case I was thinking the heap space used would be 2 words for the pointer + whatever is needed for the bignum 15:50:35 The value-cell is always two words. The additional cost of storing a fixnum is nothing, because a fixnum is an immediate value. If it overflows to a bignum, you will pay the allocation cost for a bignum as well as for a fixnum. 15:50:47 Now, in the bignum case, would there be a widetag for it as well? 15:51:16 And the bignums should start out at two words, one for the header (with the widetag) and one for the low n-word-bits of bignum. 15:51:18 everything that's stored on the heap has a header word, except for conses (... path dependence) 15:51:38 Once that overflows, it goes to four words, with three words for the bignum. 15:51:55 (Well, three words for the bignum bits, one word for the header.) 15:53:00 I highly recommend reading the relevant chapter in the internals manual, along with the source thereof (there are some comments in there that don't end up in the output). 15:56:59 nyef: I will 15:57:09 thanks for the patience to explain this to me. 16:34:41 Phooodus [~foo@68.107.217.139] has joined #sbcl 16:35:35 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 260 seconds] 17:07:22 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: gogogo] 17:15:08 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:38:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 17:46:57 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 258 seconds] 18:00:55 akovalen` [~anton@95.73.107.146] has joined #sbcl 18:02:30 -!- akovalenko [~anton@77.51.3.36] has quit [Ping timeout: 240 seconds] 18:03:28 -!- akovalen` is now known as akovalenko 18:54:01 homie` [~levgue@xdsl-84-44-153-252.netcologne.de] has joined #sbcl 18:56:38 -!- homie [~levgue@xdsl-78-35-177-149.netcologne.de] has quit [Ping timeout: 258 seconds] 19:02:34 -!- akovalenko [~anton@95.73.107.146] has quit [Remote host closed the connection] 19:16:11 akovalenko [~anton@95.73.107.146] has joined #sbcl 19:17:06 -!- akovalenko [~anton@95.73.107.146] has quit [Read error: Connection timed out] 19:19:57 akovalenko [~anton@95.73.107.146] has joined #sbcl 20:09:42 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Operation timed out] 20:25:00 prxq [~mommer@mnhm-590c2c71.pool.mediaWays.net] has joined #sbcl 20:37:14 antgreen [~user@bas3-toronto06-1177889969.dsl.bell.ca] has joined #sbcl 21:44:36 -!- prxq [~mommer@mnhm-590c2c71.pool.mediaWays.net] has quit [Quit: Leaving] 22:43:57 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 22:59:02 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 23:08:54 -!- sdemarre [~serge@91.176.92.106] has quit [Ping timeout: 240 seconds]