* 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).