unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Bytevector VM ops
       [not found] <E1MK8tN-0002tE-PI@cvs.savannah.gnu.org>
@ 2009-06-29 22:23 ` Ludovic Courtès
  2009-06-30  7:15   ` Andy Wingo
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2009-06-29 22:23 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-devel

Hello,

I'm finally looking into these new VM ops...

"Andy Wingo" <wingo@pobox.com> writes:

> +#define BV_FIXABLE_INT_REF(stem, fn_stem, type, size)                   \
> +{                                                                       \
> +  long i;                                                               \
> +  ARGS2 (bv, idx);                                                      \
> +  VM_VALIDATE_BYTEVECTOR (bv);                                          \
> +  if (SCM_LIKELY (SCM_I_INUMP (idx)                                     \
> +                  && ((i = SCM_I_INUM (idx)) >= 0)                        \
> +                  && (i < SCM_BYTEVECTOR_LENGTH (bv))                   \
> +                  && (i % size == 0)))                                  \
> +    RETURN (SCM_I_MAKINUM (*(scm_t_##type*)                             \
> +                           (SCM_BYTEVECTOR_CONTENTS (bv) + i)));        \

Did you test this on SPARC or some such?  I'm 90% sure
`(bv-u32-ref bv 1)' would lead to SIGBUS there, due to the unaligned access.
This is why `INTEGER_REF ()' in `bytevectors.c' uses memcpy(3).

> +  else                                                                  \
> +    RETURN (scm_bytevector_##fn_stem##_ref (bv, idx));                  \

In this case, we pay the overhead twice (type-checking et al.).

Given that there's some duplication with `bytevectors.c', maybe we could
share some of the accessor macros between both files?

Thanks,
Ludo'.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bytevector VM ops
  2009-06-29 22:23 ` Bytevector VM ops Ludovic Courtès
@ 2009-06-30  7:15   ` Andy Wingo
  2009-06-30  7:30     ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Wingo @ 2009-06-30  7:15 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guile-devel

Hi,

On Tue 30 Jun 2009 00:23, ludo@gnu.org (Ludovic Courtès) writes:

> "Andy Wingo" <wingo@pobox.com> writes:
>
>> +#define BV_FIXABLE_INT_REF(stem, fn_stem, type, size)                   \
>> +{                                                                       \
>> +  long i;                                                               \
>> +  ARGS2 (bv, idx);                                                      \
>> +  VM_VALIDATE_BYTEVECTOR (bv);                                          \
>> +  if (SCM_LIKELY (SCM_I_INUMP (idx)                                     \
>> +                  && ((i = SCM_I_INUM (idx)) >= 0)                        \
>> +                  && (i < SCM_BYTEVECTOR_LENGTH (bv))                   \
>> +                  && (i % size == 0)))                                  \
>> +    RETURN (SCM_I_MAKINUM (*(scm_t_##type*)                             \
>> +                           (SCM_BYTEVECTOR_CONTENTS (bv) + i)));        \
>
> Did you test this on SPARC or some such?  I'm 90% sure
> `(bv-u32-ref bv 1)' would lead to SIGBUS there, due to the unaligned access.
> This is why `INTEGER_REF ()' in `bytevectors.c' uses memcpy(3).

Wouldn't the i % size == 0 case catch that? (This is used in native-ref
instructions) 

>> +  else                                                                  \
>> +    RETURN (scm_bytevector_##fn_stem##_ref (bv, idx));                  \
>
> In this case, we pay the overhead twice (type-checking et al.).

It's probably an error -- idx is not an inum, is out of range, or is
unaligned...

> Given that there's some duplication with `bytevectors.c', maybe we could
> share some of the accessor macros between both files?

Perhaps! The one difference is that we can fast-path only the normal
cases here, calling out to those functions to handle stranger things
(like unaligned access).

Andy
-- 
http://wingolog.org/




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bytevector VM ops
  2009-06-30  7:15   ` Andy Wingo
@ 2009-06-30  7:30     ` Ludovic Courtès
  0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2009-06-30  7:30 UTC (permalink / raw)
  To: guile-devel

Good morning,

Andy Wingo <wingo@pobox.com> writes:

> On Tue 30 Jun 2009 00:23, ludo@gnu.org (Ludovic Courtès) writes:
>
>> "Andy Wingo" <wingo@pobox.com> writes:
>>
>>> +#define BV_FIXABLE_INT_REF(stem, fn_stem, type, size)                   \
>>> +{                                                                       \
>>> +  long i;                                                               \
>>> +  ARGS2 (bv, idx);                                                      \
>>> +  VM_VALIDATE_BYTEVECTOR (bv);                                          \
>>> +  if (SCM_LIKELY (SCM_I_INUMP (idx)                                     \
>>> +                  && ((i = SCM_I_INUM (idx)) >= 0)                        \
>>> +                  && (i < SCM_BYTEVECTOR_LENGTH (bv))                   \
>>> +                  && (i % size == 0)))                                  \
>>> +    RETURN (SCM_I_MAKINUM (*(scm_t_##type*)                             \
>>> +                           (SCM_BYTEVECTOR_CONTENTS (bv) + i)));        \
>>
>> Did you test this on SPARC or some such?  I'm 90% sure
>> `(bv-u32-ref bv 1)' would lead to SIGBUS there, due to the unaligned access.
>> This is why `INTEGER_REF ()' in `bytevectors.c' uses memcpy(3).
>
> Wouldn't the i % size == 0 case catch that? (This is used in native-ref
> instructions) 

Oh yes, probably, I had overlooked this.

>> Given that there's some duplication with `bytevectors.c', maybe we could
>> share some of the accessor macros between both files?
>
> Perhaps! The one difference is that we can fast-path only the normal
> cases here, calling out to those functions to handle stranger things
> (like unaligned access).

Right.  So maybe the macros are different enough that we'd be better off
keeping things as they are.

Thanks,
Ludo'.





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-06-30  7:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1MK8tN-0002tE-PI@cvs.savannah.gnu.org>
2009-06-29 22:23 ` Bytevector VM ops Ludovic Courtès
2009-06-30  7:15   ` Andy Wingo
2009-06-30  7:30     ` Ludovic Courtès

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).