[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
[EMAIL PROTECTED]:
(No, I don't know why unaligned access to 8-bit data is faster, but there
you go)
How *do* you unalign 8-bit data?!
MfG Kai
[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
[EMAIL PROTECTED]:
*) All private routines have #defines to give them a _Perl_ prefix
*) All private data have #defines to give them a _PL_ prefix
IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved
for the
At 12:15 AM 4/13/2001 +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
[EMAIL PROTECTED]:
(No, I don't know why unaligned access to 8-bit data is faster, but there
you go)
How *do* you unalign 8-bit data?!
(Must... resist... straight... line...)
On a
At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
[EMAIL PROTECTED]:
*) All private routines have #defines to give them a _Perl_ prefix
*) All private data have #defines to give them a _PL_ prefix
IIRC, ISO C says you cannot have
Dan Sugalski wrote on 4/11/01 13.38:
At 03:09 PM 4/11/2001
-0400, John Siracusa wrote:
On 4/11/01 10:55 AM, Dan
Sugalski wrote:
It does fix the link issues,
though. perl6.so won't ever
have an
unqualified function in
it--they'll all have either a
Perl_ or _Perl_
prefix on them, and all
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The only difference between the aligned and unaligned runs is the
DS pointer to the aligned data is on an 8-byte boundary, and the
DS unaligned data is the aligned pointer plus 1.
i am assuming this is an alpha (which i got to know too
IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved
for the standard.
If you consider our prefix is "_Perl_" not just "_", we will be pretty safe.
There are just not many people follow the standard anyway :-)
Hong
