public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/99435] New: avr: incorrect I/O address ranges for some cores
@ 2021-03-06 20:15 gcc at nothien dot uber.space
  2022-10-26 21:21 ` [Bug target/99435] " gjl at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: gcc at nothien dot uber.space @ 2021-03-06 20:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435

            Bug ID: 99435
           Summary: avr: incorrect I/O address ranges for some cores
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at nothien dot uber.space
  Target Milestone: ---

The `io' and `io_low' attributes incorrectly report out-of-range addresses when
compiling for the ATmega32u4 (-mmcu=atmega32u4), on all GCC versions.

In particular, on this core, the 'low' I/O address space (within which the
instructions sbi, cbi, sbis, sbic, etc. can be used, in addition to memory
reads/writes) is from 0x20 to 0x5F (inclusive; 64 bytes), and the 'high' I/O
address space (which can only be accessed only using memory reads/writes) is
from 0x60 to 0xFF (inclusive; 160 bytes).

The datasheet for the ATmega32u4 (and the ATmega16u4), which discusses these
ranges (see section 5), can be found at
<http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf>.

Compiling, for example, the following (with `avr-gcc -Wall -Wextra -Wpedantic
-Werror -mmcu=atmega32u4`):

    volatile uint8_t io_pllcsr __attribute__((io_low (0x49)));

will fail with the error: "‘io_low’ attribute address out of range", although
this is a perfectly valid low I/O address on this platform.

This error occurs because currently GCC assumes that the low I/O address space
is from 0x20 to 0x3F and that the high I/O address space is from 0x40 to 0x5F. 
These limits are hardcoded into the `low_io_address_operand',
`high_io_address_operand', and `io_address_operand' predicates, defined at
`gcc/config/avr/predicates.md'.

This should be corrected by moving these values into the avr_arch structure,
where they can be varied by platform.  I will send in a patch for this shortly.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/99435] avr: incorrect I/O address ranges for some cores
  2021-03-06 20:15 [Bug target/99435] New: avr: incorrect I/O address ranges for some cores gcc at nothien dot uber.space
@ 2022-10-26 21:21 ` gjl at gcc dot gnu.org
  2023-01-25 18:28 ` gjl at gcc dot gnu.org
  2023-05-28 10:49 ` gjl at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: gjl at gcc dot gnu.org @ 2022-10-26 21:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435

--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I am really confused.

To all of my knowledge, IN and OUT can address a range of 64 bytes.  For
example, the opcode of OUT is

1011 1AAr rrrr AAAA

where "r" bits encode for the register number (2^5 = 32 of them) and "A" bits
encode absolute target addresses (2^6 = 64 of them). So there isn't even enough
space in the instruction encoding to provide an address range as clained by
this PR.

Similar for, say, SBI with opcode encoding

1011 1010 AAAA Abbb

where "A" bits encode for absolute target address (2^5 = 32 of them) and "b"
encode target bit number (2^3 = 8 of them).

Are you sure you didn't just stumble upon a typo in the data sheet?

All AVRs are using these encodings.  The only difference is between Xmega and
non-Xmega which use different, implicit SFR_OFFSETs (which don't affect the
encoding or the number of address that can be encoded).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/99435] avr: incorrect I/O address ranges for some cores
  2021-03-06 20:15 [Bug target/99435] New: avr: incorrect I/O address ranges for some cores gcc at nothien dot uber.space
  2022-10-26 21:21 ` [Bug target/99435] " gjl at gcc dot gnu.org
@ 2023-01-25 18:28 ` gjl at gcc dot gnu.org
  2023-05-28 10:49 ` gjl at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-01-25 18:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-01-25

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Still wainting for a reply.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/99435] avr: incorrect I/O address ranges for some cores
  2021-03-06 20:15 [Bug target/99435] New: avr: incorrect I/O address ranges for some cores gcc at nothien dot uber.space
  2022-10-26 21:21 ` [Bug target/99435] " gjl at gcc dot gnu.org
  2023-01-25 18:28 ` gjl at gcc dot gnu.org
@ 2023-05-28 10:49 ` gjl at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-05-28 10:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Closed as invalid.

The linked ATmega16U4 states on page 26:

> 5. AVR Memories
> 5.4 I/O Memory
> [...]
> I/O Registers within the address range 0x00 - 0x1F are directly bit-accessible
> using the SBI and CBI instructions. In these registers, the value of single
> bits can be checked by using the SBIS and SBIC instructions. Refer to the
> instruction set section for more details. When using the I/O specific commands
> IN and OUT, the I/O addresses 0x00 - 0x3F must be used. When addressing I/O
> Registers as data space using LD and ST instructions, 0x20 must be added to
> these addresses. The device is a complex microcontroller with more peripheral
> units than can be supported within the 64 location reserved in Opcode for the
> IN and OUT instructions. For the Extended I/O space from 0x60 - 0xFF in SRAM,
> only the ST/STS/STD and LD/LDS/LDD instructions can be used.

So the lower I/O has a range of 5 bits (CBI, SBI, SBIC, SBIS), and the I/O
addressable by IN and OUT has a range of 6 bits.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-05-28 10:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-06 20:15 [Bug target/99435] New: avr: incorrect I/O address ranges for some cores gcc at nothien dot uber.space
2022-10-26 21:21 ` [Bug target/99435] " gjl at gcc dot gnu.org
2023-01-25 18:28 ` gjl at gcc dot gnu.org
2023-05-28 10:49 ` gjl at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).