(idle curiosity) Did any version of perl ever build on a system with CHAR_BIT != 8

[Peter Rabbitson]

Just figured I will repost my perlmonks question[1] here:

Two questions in one really:
* Did any version of perl ever build on a system with CHAR_BIT != 8?
* If so - is there a way to find the value from *within perl itself* (i.e. no gcc, no Inline::C, no XS, etc)?

There is absolutely no practical reason for this question, I am just
curious.

Cheers

[1] http://www.perlmonks.org/?node_id=1022443

[Zefram]

Peter Rabbitson wrote:
>* If so - is there a way to find the value from *within perl itself* (i.e. no gcc, no Inline::C, no XS, etc)?

The value of CHAR_BIT would only ever be 8 or 9, and the latter only
on older versions. You could look at things like chr(256) and "\400"
to see whether you get a byte with value 256, after checking that $] <
5.006 to make sure you don't get misled by Unicode support.

-zefram

[Peter Rabbitson]

On Fri, Mar 08, 2013 at 05:57:22PM +0000, Zefram wrote:
> Peter Rabbitson wrote:
> >* If so - is there a way to find the value from *within perl itself* (i.e. no gcc, no Inline::C, no XS, etc)?
>
> The value of CHAR_BIT would only ever be 8 or 9, and the latter only
> on older versions.

Can you clarify please? Is this an answer to "was perl ever built..." or
is this more of a statement like "perl can only buld on 8/9 bit bytes,
and nothing higher"?

Cheers

[Karl Williamson]

AFAIK the maximum of any computer ever made was CHAR_BIT == 9.

There are more than several tables in Perl that are 256 entries long and
are indexed by the character number. If that number is more than 8
bits, reads of those tables could be out-of-bounds.


Last I knew, the only 9-bit bytes extant are in embedded systems that
have less than 65K address spaces, so modern Perls couldn't operate on
them anyway.

Manufacturers found out quickly that having a non-8bit byte length led
to huge portability problems

[Nicholas Clark]

On Fri, Mar 08, 2013 at 11:49:42AM -0700, Karl Williamson wrote:

> Last I knew, the only 9-bit bytes extant are in embedded systems that
> have less than 65K address spaces, so modern Perls couldn't operate on
> them anyway.

commit 5869b1f143426909d25f97cd2df1d47cc4159ed3
Author: Jarkko Hietaniemi <j...@iki.fi>
Date: Fri Sep 8 21:18:10 2000 +0000

Do away with memory models cruft. Sorry, PDP users.

p4raw-id: //depot/perl@7041




PDPs were 36 bit words and 9 bit bytes?

Implication of that commit is that perl used to build on PDPs

Nicholas Clark

[Uri Guttman]

dec used pdp for all their models which had from 12 to 16 to 36 bit
words. the pdp-8 was 12 bit, pdp-11 had 16 (with 8 bit bytes) and the
pdp 10/20 had 36 bit words but with variable (yes, variable!) length
bytes. i learned c on a dec 20 and to simplify the compiler they used 1
word (36 bits) for each char. it wasn't until the vax that dec made a 32
bit machine with 8 bit bytes. the alpha was one of the first 64 bitters
also with 8 bit bytes (that had a set of instructions to access any byte
from a 64 bit word).

so the comment from jarkko could refer to any of the non-vax pdp models
as they didn't have 8 bit bytes in a vm. did perl ever run on a pdp-11?
unix was propogated early on on 11's but it had only a 64k ram space so
perl would have been nigh impossible on it.

uri

[Aaron Crane]

Nicholas Clark <ni...@ccl4.org> wrote:
> commit 5869b1f143426909d25f97cd2df1d47cc4159ed3
> Author: Jarkko Hietaniemi <j...@iki.fi>
> Date: Fri Sep 8 21:18:10 2000 +0000
>
> Do away with memory models cruft. Sorry, PDP users.
>
> p4raw-id: //depot/perl@7041
>
> PDPs were 36 bit words and 9 bit bytes?

PDP-10s were, I believe; PDP-11s were 8-bit bytes and 16-bit words
(with split address spaces for instructions and data in later models).

> Implication of that commit is that perl used to build on PDPs

I think it means PDP-11s (presumably running some flavour of Unix) —
the "models cruft" it refers to is related to the split-I&D mode I
mention above, AFAICT.

--
Aaron Crane ** http://aaroncrane.co.uk/

[Nicholas Clark]

In the bath I remembered that Nick Ing-Simmons certainly made reference to
an embedded system where chars were 32 bit (hence sizeof(long) was 1)
I think that this was when he worked for Texas Instruments. I'm not sure if
he also said that he built perl on it.

So there is an answer to not 8, it's more likely to be 32 than 9.

Nicholas Clark

[Craig A. Berry]

There is lots of information on the old DEC processors at:

http://simh.trailing-edge.com/hardware.html

including simulators in case you want to fire them up at home. PDP-10
was EOL in 1983 and as far as I could find never supported Ultrix, so
I think that confirms the answer to the OP's question is almost
certainly no.

Side note: we still have a handful of references to Ultrix in the
code, and we could probably remove those safely.

[Leon Timmermans]

I remember seeing references suggesting Crays also had such 'interesting' sizes.

Leon

[Paul Johnson]

On Fri, Mar 08, 2013 at 03:13:13PM -0600, Craig A. Berry wrote:

> Side note: we still have a handful of references to Ultrix in the
> code, and we could probably remove those safely.

This made me wonder whether we still support any systems which don't
have dynamic loading. And then I wondered whether it is still useful to
support building extensions statically.

I suspect the answers are no and yes or maybe yes and yes. But if
they're no and no, then there's plenty of other code to be removed.

--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net

[Green, Paul]

Until fairly recently, the Stratus VOS operating system did not support
dynamic linking. Thankfully, that omission was remedied about 2 years
ago with the introduction of OpenVOS 17.2. So from our (my) point of
view, it is OK to remove support for static-linking-only. Though I have
to say, it is a lot easier to debug statically-linked stuff.

PG

-----Original Message-----
From: Paul Johnson [mailto:pa...@pjcj.net]
Sent: Friday, March 08, 2013 5:59 PM
To: Craig A. Berry
Cc: Aaron Crane; Nicholas Clark; Perl5 Porters
Subject: Re: (idle curiosity) Did any version of perl ever build on a
system with CHAR_BIT != 8

[Brad Gilbert]

I'm fairly confident that the DJGPP port requires extensions to
be statically linked. Although the newest available version is 5.8.8
built in 2007 (http://www.delorie.com/pub/djgpp/current/v2gnu/)

As for allowing some modules to be statically linked; it does appear
to be used by the Cygwin, and native Win32 ports.

hints/cygwin.sh:

# compile Win32CORE "module" as static. try to avoid the space.
if test -z "$static_ext"; then
static_ext="Win32CORE"
else
static_ext="$static_ext Win32CORE"
fi

win32/makefile.mk:

.IF "$(ALL_STATIC)" == "define"
# some exclusions, unfortunately, until fixed:
# - Win32 extension contains overlapped symbols with win32.c (BUG!)
# - MakeMaker isn't capable enough for SDBM_File (smaller bug)
# - Encode (encoding search algorithm relies on shared library?)
STATIC_EXT = * !Win32 !SDBM_File !Encode
.ELSE
# specify static extensions here, for example:
#STATIC_EXT = Cwd Compress/Raw/Zlib
STATIC_EXT = Win32CORE
.ENDIF

win32/Makefile:

!IF "$(ALL_STATIC)" == "define"
# some exclusions, unfortunately, until fixed:
# - Win32 extension contains overlapped symbols with win32.c (BUG!)
# - MakeMaker isn't capable enough for SDBM_File (smaller bug)
# - Encode (encoding search algorithm relies on shared library?)
STATIC_EXT = * !Win32 !SDBM_File !Encode
!ELSE
# specify static extensions here, for example:
#STATIC_EXT = Cwd Compress/Raw/Zlib
STATIC_EXT = Win32CORE
!ENDIF

[Andreas Koenig]

Recommended reading https://rt.perl.org/rt3//Public/Bug/Display.html?id=79494

--
andreas

[Leon Timmermans]

On Fri, Mar 8, 2013 at 11:58 PM, Paul Johnson <pa...@pjcj.net> wrote:
> This made me wonder whether we still support any systems which don't
> have dynamic loading. And then I wondered whether it is still useful to
> support building extensions statically.
>
> I suspect the answers are no and yes or maybe yes and yes. But if
> they're no and no, then there's plenty of other code to be removed.

https://metacpan.org/release/App-Staticperl

Yes, some people apparently still use statically compiled perls, even
when dynamic loading is present.

[Peter Rabbitson]

Being able to throw a single binary and a single kernel on a USB stick,
and have that combo work *ANYWHERE* is rather convenient.

[David Cantrell]

On Fri, Mar 08, 2013 at 10:37:21PM +0100, Leon Timmermans wrote:

> I remember seeing references suggesting Crays also had such 'interesting' sizes.

char was 8 bits on the Crays I've played with. But short == int ==
long == 64 bits, which led to some interesting portability problems -
for example, bzip2 assumes 16 bit shorts.

--
David Cantrell | Hero of the Information Age