Compiler/TM4C123GH6PM: Some Bits Read as 0 automatically,I am curious about its

liguo wang said:

Why are some bits of some registers automatically read as 0, is this done by the underlying hardware?

Which bits of which registers are you referring to?

For bits marked as reserved, see the following in the Documentation Conventions section of the datasheet:

liguo wang said:

Or is it the role of the compiler?

The compiler doesn't know details of the peripheral registers, and doesn't generate code to automatically zero reserved bits on peripheral register reads.

Greetings - always good to note your return.    You asked:

liguo wang said:

Why are some bits of some registers automatically read as 0, is this done by the underlying hardware? Or is it the role of the compiler?

Young staff & I believe that (some) history of (first) Microprocessors & (later) Microcontrollers will add depth & perspective - beyond that gleaned from any (single) MCU or vendor.

To that end - staff raided our firm's library (housing: Tech, Finance, Legal) and responds based upon content gleaned from:

• Microprocessor Systems Engineering; R.C. Camp, T.A. Smay, C.J. Triska;  (Graduate Level, hard cover course book)
• The 8051 Microcomputer - Programming, Interfacing, Applications; Howard Boyet, Ron Katz.    Both held high positions at "Bell Laboratories" a past 'Tech Powerhouse.'
• An Introduction to Microcomputers, Volume 1 Basic Concepts; Adam Osborne.

Each of those books exceeds 30 years old - yet they provide a 'baseline & history' - which strengthens our (current) understanding.    They (and others) often provide the missing link - which no single vendor's tech lit. can supply.

On a more current note - MIT, NASA & Boeing have collaborated in producing a (personal opinion follows) 'Super Tech Course:'  

This well worth an MCU developer's visit & (even) extended investigation.     (it may be noted that MIT, NASA & Boeing are all 'cb1-firm' clients...)

Historically Register bits were most often "Inactive" when defaulting to '0.'    This was achieved via the Processor/Controller's biasing - and usually could be toggled by the user via software settings.   The books noted earlier stated that the Register Bits which were, "Read as '1' were "More easily recognizable" and thus likely to be 'Active' when set to that '1' state.   Thus your 'answer' is - as you well thought - 'Underlying hardware!'     However - though rare - a few compilers, "Did have the ability to automatically (i.e. w/out user intervention) alter certain Registers - this to: 'Correct Mistakes' and/or 'better mesh w/majority user needs!'

To illustrate - we include a '123 MCU Register - which reveals a 'mix' of '0s & 1s' (as default) and which (clearly) complies w/your, 'Underlying Hardware' intuition.    (Key bits must NOT be 'alterable' - either deliberately or thru program/user 'mistake!')

It is believed that your 'free' download of a 'Pro' IDE (IAR or Keil) will enhance your MCU Development as both are 'Vendor Agnostic' - have long pre-existed 'single vendor only IDEs' - and offer features & capabilities commensurate w/their much larger (and continuing) development staff - not equaled by (any) vendor-restricted offering...   (to Self-Limit one's MCU selection proves difficult to justify - MCU's should "Win their Sockets" via: Performance, Capability & Price/Availability - not via 'less direct' means...)

Thanks to Chester and cb1 for their inputs. 

Normally reserved bits are forced to 0 by hardware. There is no physical flip-flop associated with a reserved bit. You can think of them a tie-off to ground. Cb1 brought the Device ID register as an example. This is another type of 'logical' register that is not implemented using flip-flop. Rather than tied-off to 0 like the reserved fields, they are tied to high or low per their intended values.