Re: PR1ME C compiler sources

From	George Neuner <gneuner2@comcast.net>
Newsgroups	comp.compilers
Subject	Re: PR1ME C compiler sources
Date	2019-09-27 20:56 -0400
Organization	A noiseless patient Spider
Message-ID	<19-09-015@comp.compilers> (permalink)
References	<19-09-003@comp.compilers> <19-09-004@comp.compilers> <19-09-006@comp.compilers> <19-09-007@comp.compilers> <19-09-009@comp.compilers>

Show all headers | View raw

On Thu, 26 Sep 2019 11:53:20 +0100, "Derek M. Jones"
<derek@_NOSPAM_knosof.co.uk> wrote:

>John,
>
>> [The Prime machines suffered from having too many versions of
>> everything.  Page 41 of that quick reference card has a 48 bit pointer
>> format with a bit number in the low 16 bits.  It seems unlikely that a
>> C compiler would use that as a general pointer format since it doesn't
>> fit in any sort of normal int, and it's not what you'd want to point
>> at an int or a function or anything bigger than a char. -John]
>
>Some Cray machines and DSP chips have a similar problem with using
>word addressing.
>
>Several solve the problem by defining the word to be the smallest
>addressable unit, making chars 48-bits in the case of some DSPs.

Just curious - what DSPs have 48-bit characters?

I have worked with Analog Devices chips that had 16/32/48 bit words in
internal memory and 32/48 bit words in external memory.  Instructions
- and extended floats - were 48 bit, but all other data was either 16
or 32 bit. Due to addressing, an individual character could be a 16 or
32 bit value in internal memory, but had to be a 32-bit value in
external memory.  Strings - if you used them - were packed to occupy
as few words as possible, and library string functions (mostly)
expected packed sequences rather than arrays of characters.

George

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-25 15:27 +0100
  Re: PR1ME C compiler sources arnold@skeeve.com (Aharon Robbins) - 2019-09-25 18:32 +0000
    Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:02 -0500
      Re: PR1ME C compiler sources arnold@skeeve.com (Aharon Robbins) - 2019-09-26 10:57 +0000
    Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:04 -0500
      Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 20:28 -0500
        Re: PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-26 11:53 +0100
          Re: PR1ME C compiler sources drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-27 10:19 -0500
            Re: PR1ME C compiler sources "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-28 00:48 +0100
              Re: PR1ME C compiler pointer management drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-28 11:08 -0500
                Re: PR1ME C compiler sources and pointer formats Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2019-09-29 07:48 -0400
                Re: PR1ME C compiler sources and pointer formats drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-30 22:10 -0500
          Re: PR1ME C compiler sources George Neuner <gneuner2@comcast.net> - 2019-09-27 20:56 -0400
            Re: C compiler pointer management on DSPs "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-09-28 19:19 +0100
              Re: C compiler pointer management on DSPs David Brown <david.brown@hesbynett.no> - 2019-09-29 10:53 +0200
                Re: C compiler pointer management on DSPs Kaz Kylheku <847-115-0292@kylheku.com> - 2019-09-30 23:50 +0000
                Re: C compiler pointer management on DSPs George Neuner <gneuner2@comcast.net> - 2019-10-03 01:34 -0400
                Re: C compiler pointer management on DSPs gah4@u.washington.edu - 2020-02-27 14:23 -0800
                Re: C compiler pointer management on DSPs robin51@dodo.com.au - 2020-02-28 10:26 +1100
                Re: C compiler pointer management on DSPs gah4@u.washington.edu - 2020-02-28 02:33 -0800

csiph-web