Re: C compiler pointer management on DSPs

From	gah4@u.washington.edu
Newsgroups	comp.compilers
Subject	Re: C compiler pointer management on DSPs
Date	2020-02-27 14:23 -0800
Organization	Compilers Central
Message-ID	<20-02-024@comp.compilers> (permalink)
References	(3 earlier) <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>

Show all headers | View raw

On Monday, September 30, 2019 at 3:06:36 PM UTC-7, David Brown wrote:

(snip)

> Some processors have larger access sizes to simplify the hardware.  The
> first DEC Alpha, and some ARM designs, had no instructions for reading
> or writing 8-bit or 16-bit data.  In effect, these had 32-bit (maybe on
> the Alpha it was 64-bit) "byte" sizes.  But smaller access sizes could
> be easily simulated in software.

Alpha isn't quite that bad.

The load/store instructions work on 32 or 64 bit units, but they ignore
the low bits when doing it.

So, you take a byte address, and use a load instruction to load its
word into a register.  (I forget now the names of the memory units.)

Then there are instructions for operating on bytes
in a register which ignore the high bits.  So, you can load a byte
from memory into a register with two instructions.  To store a byte,
I believe you load the word, replace the byte, and write it back,
so three instructions.

Note that those operations are what CISC processors do without
you thinking about them on many machines, as memory is often
much wider than 8 bits.

Machines not so well designed require masking off the appropriate
bits before operating with them, though many machines ignore high
bits on shift operations.  (The 8086 allows shifts up to 255 bits.)

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