freenode/#lisp - IRC Chatlog
Search
8:53:01
heisig
Is there any modern Lisp implementation that does not represent single-floats as 32bit IEEE floats and double-floats as 64bit IEEE floats?
9:32:00
heisig
loke: Modern as in - I don't plan to support Genera (at least for this particular project).
9:33:20
edgar-rft
heisig: I'm quite sure that this is not what you're looking for, but PicoLisp is a modern Lisp that represents floats by integer tricks (no IEEE floats involved), see https://www.the-m6.net/blog/fixed-point-arithmetic-in-picolisp/
9:35:33
heisig
loke: I'm asking because I am working on a portable type inference and function specialization library.
9:36:15
heisig
And I'm thinking about things like GPU offloading for some programs, so it is important for me to figure out which Lisp types correspond to which C/OpenCL/CUDA types.
9:36:42
heisig
If I can reasonably assume that single-float is a 32bit IEEE float, that simplifies a lot.
9:37:17
heisig
loke: By the way, I just read the CLISP documentation and it seems that single-float and double-float are IEEE 754 floats.
9:38:30
heisig
loke: Can you elaborate? So far, the only problems I see is the behavior with respect to over- and underflow and infinities.
9:41:44
jackdaniel
also it is worth noting, that long-float in ecl defaults to long double C type while in sbcl long-float is the same thing as double-float
9:42:07
jackdaniel
and that no implementation I'm aware of implements short-float as 16bit IEEE float :)
9:44:40
jackdaniel
pointer has the same amount of memory disregarding how many bits has the underlying object
9:44:50
loke
If you crate an array of N short-floats, I'd want that array to occupy 4*N bytes o fmemory
9:44:54
beach
loke: There would very likely be a specialized array type that would store them unboxed.
9:46:47
heisig
Let me point out that I don't care about short-floats and long-floats. Or rather, I acknowledge that there is no consensus in CL on how they ought to be represented.
9:46:49
beach
loke: I still don't understand. If you have an unspecialized array, your 30-bit floats would still take up a full pointer.
9:48:24
loke
beach: It uses 64-bit pointers/values, but if the top 32 bits are zeroes, they only occupy 4 bytes of storage.
9:50:27
loke
The heap doesn't have to be located at address zero. Pointers are an offet from heap start.
9:51:07
loke
Because if a Lisp implementation wanted to implement this, they'd need tagging, which I presume would occupy at least two bits.
9:51:56
jackdaniel
loke: I don't think that any CL implementation does change memory address size at runtime
9:52:17
jackdaniel
and I can imagine how tedious that would be (especially with regard to immediate types)
9:52:40
loke
shka__: There are flags to control whether or not it's used. By defaul tit uses it if the heap can fit within the low 4 GB of address space (i.e. it doesn't normally use the offset trick unless requested, since it can slow things down)
9:53:42
loke
shka__: I didn't know about it either until our application at work started failing weirdly. Turns out aht because we embed a JVM, an dby default packing is enabled, it hard-located its heap just below the 4 GB limit, so when the C++ code wanted to allocated more memort, BOOM. The break pointer crashed into the Java heap.
9:54:31
loke
jackdaniel: I've worked so much with the JVM recently, that I kind of instinctively think about this stuf fin JVM terms. :-) Soryr about that.
9:55:30
loke
jackdaniel: Yeah. And it wasn't obvious at first. It was kind of easy to note that the Java heap was blocking the C++ malloc() function, since there was a JVM-sized [anon] block in the heap map.
9:55:31
jackdaniel
imo specialized arrays are good enough for saving space, and if you want to be generic all the way down then you need to deal with addresses which won't surprise you at random time ,)
9:56:16
loke
Figuring out why the JVM wnated to be below 4 GB was the tricky part. There wasn't anything obvious to good for. I can't remember how I found the documentation on it.
9:56:22
shka__
beach: quick question regarding sbcl immobile spaces: it is an issue with just generic functions, and not just with any funcallable object?
9:57:48
heisig
loke: You still haven't told me why I shouldn't assume that single-float and double-float are IEEE 754 floats.
9:57:50
beach
It used to be all funcallable standard objects, but stassats kindly changed that for me, so that now it is only generic functions.
9:58:36
loke
heisig: Because the standard allows it to be different, and you shouldn't assume things that the standard explicitly states are unspecified. SBCL in particular tend to take advatage of these (non)-guarantees.
9:59:44
jackdaniel
heisig: it would be a good idea to add a new feature to trivial-features :ieee-floats
10:05:40
aeth
CCL doesn't seem to have single-float infinities. Or at least it's not in here. https://github.com/Shinmera/float-features/blob/master/float-features.lisp
10:14:28
scymtym
jackdaniel: if i'm not mistaken, a new feature is not needed. clhs *FEATURES* says ":ieee-floating-point If present, indicates that the implementation purports to conform to the requirements of IEEE Standard for Binary Floating-Point Arithmetic."
10:34:30
jackdaniel
I think that this is a question for #ccl developers whenever their implementation has some lackings or it was simply an omission (or functionality was implemented over time and nobody thought about adding the feature)
12:05:40
jackdaniel
or maybe not, either way I took it from /somewhere/ what was concerned about ieee conformance and atan
14:56:25
jackdaniel
"C preprocessor macros" are not available in the resulting binary after compiling with C compiler
14:58:22
LdBeth
So are there any tools can help generating wrappers if the header files are provided?
15:01:53
jackdaniel
to what extent it could be used as means to "record" preprocessor macros is not known to me
15:02:25
pjb
LdBeth: the main problem with the preprocessor, is that it depends on the preprocessing. Which can be different on each compilation,
15:02:50
pjb
LdBeth: there's no guarantee that the preprocessing done by lisp tools will give the same macro values as when the actual C library was compiled.
15:03:04
pjb
LdBeth: therefore, don't do that. Instead, design your C API to not use preprocessing macros.
15:14:18
rumbler31__
LdBeth: have you seen this? https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/
16:37:33
dim
pjb: https://github.com/Clozure/ccl/blob/master/objc-bridge/objc-runtime.lisp#L720 and https://github.com/Clozure/ccl/blob/master/level-0/X86/X8632/x8632-bignum.lisp are the “universal” links to those sources, if you need'em
17:05:21
Xach
Fade: I did not, sorry. I could not commit to it as fully as I wanted in that timeframe. I hope to try again soon.
17:07:38
Fade
I'm looking at the semi-annual review of my toolchain, and sly is at the top of my list, but it'd be a pretty intrusive change. :)
17:45:58
mfiano
Fade: If you have any questions about Sly, or my experience with it, I'd be happy to help.
17:47:38
Fade
thought I'd look at it again, but I'm not relishing the idea of tearing apart my emacs config.
17:48:45
Fade
my only real concern is that I have helm wired in all over my emacs, and it looks like sly wants company
18:01:00
mfiano
Fade: Anyway, glad you liked the video. We stream live every Saturday at 1730utc on Google Hangouts if you'd like to join the discussion.