CODEWITHSUNDEEP
cgccassemblyraspberry-piarm
Makogan
Makogan

Reputation: 9536

Why is a value vanishing after compilation with gcc?

I am doing some bare bones programming for the raspberry pi and I have run into a weird problem.

I need the value 0x80000000 to test for a specific bit. Basically, this value is critical for a hardware operation I am doing and cannot be replaced. When I generate assembly code however, the critical operation of (status & 0x80000000) seems to be deleted. That is to say, there is no "and" operation anywhere on the assembly code. However, if I change that number to say, 0x40000000. The and operation appears right where I would expect it to be. Why is that number specifically, vanishing?

This is my C code:

#include <stdint.h>

#define REGISTERS_BASE 0x3F000000
#define MAIL_BASE 0xB880  // Base address for the mailbox registers
// This bit is set in the status register if there is no space to write into the mailbox
#define MAIL_FULL 0x80000000
// This bit is set in the status register if there is nothing to read from the mailbox
#define MAIL_EMPTY 0x40000000

struct Message
{
  uint32_t messageSize;
  uint32_t requestCode;
  uint32_t tagID;
  uint32_t bufferSize;
  uint32_t requestSize;
  uint32_t pinNum;
  uint32_t on_off_switch;
  uint32_t end;
};

struct Message m =
{
  .messageSize = sizeof(struct Message),
  .requestCode =0,
  .tagID = 0x00038041,
  .bufferSize = 8,
  .requestSize =0,
  .pinNum = 130,
  .on_off_switch = 1,
  .end = 0,
};

/** Main function - we'll never return from here */
//int main(void) __attribute__((naked));
int _start(void)
{

  uint32_t mailbox = MAIL_BASE + REGISTERS_BASE + 0x18;
  volatile uint32_t status;

  do
  {
    status = *(volatile uint32_t *)(mailbox);
  }
  while((status & 0x80000000));

  *(volatile uint32_t *)(MAIL_BASE + REGISTERS_BASE + 0x20) = ((uint32_t)(&m) & 0xfffffff0) | (uint32_t)(8);

  while(1);
}

this is the assembly code:

    .cpu arm7tdmi
    .fpu softvfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 1
    .eabi_attribute 30, 6
    .eabi_attribute 34, 0
    .eabi_attribute 18, 4
    .file   "PiTest.c"
    .global m
    .data
    .align  2
    .type   m, %object
    .size   m, 32
m:
    .word   32
    .word   0
    .word   229441
    .word   8
    .word   0
    .word   130
    .word   1
    .word   0
    .text
    .align  2
    .global _start
    .type   _start, %function
_start:
    @ Function supports interworking.
    @ args = 0, pretend = 0, frame = 8
    @ frame_needed = 1, uses_anonymous_args = 0
    @ link register save eliminated.
    str fp, [sp, #-4]!
    add fp, sp, #0
    sub sp, sp, #12
    ldr r3, .L4
    str r3, [fp, #-8]
.L2:
    ldr r3, [fp, #-8]
    ldr r3, [r3]
    str r3, [fp, #-12]
    ldr r3, [fp, #-12]
                        <-THE AND OPERATION SHOULD BE HERE
    cmp r3, #0
    blt .L2
    ldr r2, .L4+4
    ldr r3, .L4+8
    bic r3, r3, #15
    orr r3, r3, #8
    str r3, [r2]
.L3:
    b   .L3
.L5:
    .align  2
.L4:
    .word   1057011864
    .word   1057011872
    .word   m
    .size   _start, .-_start
    .ident  "GCC: (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)"

Upvotes: 4

Views: 130

Answers (2)

Gerhardh
Gerhardh

Reputation: 12404

I am not really familiar with that assembler architecture. But the code looks fine for me.

Given a register size of 32 bits and storing integer values as two's complement, any value with highest bit set is representing a negative value if treated as signed.

Therefore the compiler converts the AND into a <0 comparison:

cmp r3, #0
blt .L2

Upvotes: 1

melpomene
melpomene

Reputation: 85767

The bit you're testing is the highest bit in an integer variable. If you were to treat the variable as a signed integer, it would correspond to the sign bit.

cmp r3, #0
blt .L2

This code compares r3 to 0, and if it's smaller, jumps back to .L2. I.e. the loop condition is r3 < 0, which is equivalent to testing whether the sign bit (= the highest bit) is set in r3.

Upvotes: 5

Related Questions