Re: C compiler pointer management on DSPs

Path	csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From	gah4@u.washington.edu
Newsgroups	comp.compilers
Subject	Re: C compiler pointer management on DSPs
Date	Fri, 28 Feb 2020 02:33:56 -0800 (PST)
Organization	Compilers Central
Lines	44
Sender	news@iecc.com
Approved	comp.compilers@iecc.com
Message-ID	<20-02-029@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> <19-09-015@comp.compilers> <19-09-017@comp.compilers> <19-09-018@comp.compilers> <20-02-024@comp.compilers> <20-02-025@comp.compilers>
Mime-Version	1.0
Content-Type	text/plain; charset="UTF-8"
Injection-Info	gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="98767"; mail-complaints-to="abuse@iecc.com"
Keywords	architecture, history, comment
Posted-Date	28 Feb 2020 12:27:44 EST
X-submission-address	compilers@iecc.com
X-moderator-address	compilers-request@iecc.com
X-FAQ-and-archives	http://compilers.iecc.com
Xref	csiph.com comp.compilers:2466

Show key headers only | View raw

On Thursday, February 27, 2020 at 7:03:27 PM UTC-8, rob...@dodo.com.au wrote:
> On 2020-02-28 09:23, gah4@u.washington.edu wrote:
>
> > Machines not so well designed require masking off the appropriate
> > bits before operating with them.

(snip)

> Who can say that the CDC machines (7600; 70 series, etc) were not
> well designed?

> They were intended to be fast, and to carry out operations on
> words (of 60 bits).

CDC machines are designed for fast floating point number crunching.

They are not necessarily designed for fast character manipulation,
as that is supposed to be a relatively small part of the work.

The hardware/software tradeoffs were different so many years ago.

My favorite one has always been how the IBM 704 (and I believe
later 36 bit machines) read in cards. The read row-wise, each row
into two 36 bit words, leaving off 8 columns. This is also the reason
why Fortran (fixed form) uses columns 1-72.

Anyway, after the compiler reads in a card row-wise, it has to
convert to columnwise (six characters per word), including converting
to the appropriate character code. But it presumably saves a lot of
logic in the card reader, where it would be expensive and could be
done in software.   The 7094 was the high-end number cruncher at
the time, including its use for S/360 emulation during its development.

But actually, as well as I know, the more usual way to run such
machines was to copy cards to tape, presumably in a cheaper machine,
so that the fast machine didn't waste so much time.

I don't know about the 60 bit machines, but there are stories
about C compilers for Cray machines using 64 bit char.

As with the CDC machines, Cray machines are designed for fast floating
point, and not so fast for fixed point.
[This is getting rather far from compilers but would be totally on-topic
in alt.folklore.computers. -John]

Back to comp.compilers | Previous | Next — Previous 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