[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-151 (Bitwise Operations) Implementation
From: |
Linus Björnstam |
Subject: |
Re: SRFI-151 (Bitwise Operations) Implementation |
Date: |
Fri, 10 Jan 2020 07:59:22 +0100 |
User-agent: |
Cyrus-JMAP/3.1.7-740-g7d9d84e-fmstable-20200109v1 |
To clarify: guile does not yet do cross module inlining. It was mentioned as a
potential thing in the thread about native guile SHA2(?) implementation. As
such there is nothing to learn about it. Potential heuristics and how to make
it clear to the optimizer what is simple re-exports I leave to Andy, Ludo, and
Mark, but I feel safe saying that #:re-export is the safest bet.
--
Linus Björnstam
On Fri, 10 Jan 2020, at 06:15, Frank Terbeck wrote:
> Hi,
>
> Linus Björnstam wrote:
> > I just re-read my message and noticed it could come off as somewhat
> > dismissive.
> > Ah, the joys of not having English as a first language while being a tired
> > father :)
>
> Didn't strike me particularly as such. So, all is good.
>
>
> > I looked through your code. It is nicer than mine, but why did you chose to
> > not
> > just re-export bindings that are available in srfi60? I don't know the
>
> I actually didn't think about it too much. I was more focused on making
> the implementation match the order used in the specification and add
> documentation to all API so it can be followed in a straight forward
> manner.
>
>
> > practical implications of not doing so, but I read in another thread of
> > potential cross-module Inlining, and helping that optimization in every way
> > you
> > can would be a great thing for low level stuff like bit fiddling :)
>
> Sure. I must admit that I haven't really played a lot with Guile's com-
> piler and optimiser. I wonder what the impact would be here. Remember
> the subject of said thread?
>
>
> Regards, Frank
> --
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
> -- RFC 1925
>