• Locked Locked
  • Replies 8 replies
  • Subscribers 136 subscribers
  • Views 5133 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Hardware Implementation

mariam

hi i created a hardware that calculates the square root of (a^2+b^2 )

i sent the inputs (a and b) with assembly and that was fine however when i tried to send them using c code the hardware take them as inputs calculates a^2 + b^2 but never do the square root

i am really clueless here i couldn't locate the problem

heeeeeeeeeeeeeeelp

Parents
  • in reply to mariam

    Well, can you use objdump -d on the bugged binary file and paste the output here.

    I do not think that the variable definition is the problem here. However, one way to be sure is to try defining regdistance within main like this :

    volatile int *regdistance = (int*)0x59000000;

    And see if it works.

    Note that you might want to replace 

    for (i = 0; i < 10; i++)

    by 

    for (i = 0; i < 9; i++)

    else you will write into places you did not define (xd[9+1] is not defined).

    However, the "at" behaviour can also be emulated doing something like :

    test.c

    volatile int input_address __attribute__ ((section ("regdistance")));

int calculate(int a, int b) {
  while(1) {
    input_address = a;
    input_address = b;
  }
}

    Using a linker script like this :

    test.ld

    ENTRY(calculate)
    SECTIONS
    {
      . = 0x10000;
      .text : { *(.text*) }
      . = 0x59000000;
      .regdistance : { *(regdistance*) }
    }

    And then compile like this :

    armv7a-hardfloat-linux-gnueabi-gcc -O3 -nostdlib -mthumb -T test.ld -o test test.c

    Code produced :

    LANG=C armv7a-hardfloat-linux-gnueabi-objdump -d test

    test:    file format elf32-littlearm

    Disassembly of section .text:

    00010000 <calculate>:
  10000:      f240 0300      movw    r3, #0
  10004:      f6c5 1300      movt    r3, #22784      ; 0x5900
  10008:      6018            str    r0, [r3, #0]
  1000a:      6019            str    r1, [r3, #0]
  1000c:      e7fc            b.n    10008 <calculate+0x8>
  1000e:      bf00            nop
Reply
  • in reply to mariam

    Well, can you use objdump -d on the bugged binary file and paste the output here.

    I do not think that the variable definition is the problem here. However, one way to be sure is to try defining regdistance within main like this :

    volatile int *regdistance = (int*)0x59000000;

    And see if it works.

    Note that you might want to replace 

    for (i = 0; i < 10; i++)

    by 

    for (i = 0; i < 9; i++)

    else you will write into places you did not define (xd[9+1] is not defined).

    However, the "at" behaviour can also be emulated doing something like :

    test.c

    volatile int input_address __attribute__ ((section ("regdistance")));

int calculate(int a, int b) {
  while(1) {
    input_address = a;
    input_address = b;
  }
}

    Using a linker script like this :

    test.ld

    ENTRY(calculate)
    SECTIONS
    {
      . = 0x10000;
      .text : { *(.text*) }
      . = 0x59000000;
      .regdistance : { *(regdistance*) }
    }

    And then compile like this :

    armv7a-hardfloat-linux-gnueabi-gcc -O3 -nostdlib -mthumb -T test.ld -o test test.c

    Code produced :

    LANG=C armv7a-hardfloat-linux-gnueabi-objdump -d test

    test:    file format elf32-littlearm

    Disassembly of section .text:

    00010000 <calculate>:
  10000:      f240 0300      movw    r3, #0
  10004:      f6c5 1300      movt    r3, #22784      ; 0x5900
  10008:      6018            str    r0, [r3, #0]
  1000a:      6019            str    r1, [r3, #0]
  1000c:      e7fc            b.n    10008 <calculate+0x8>
  1000e:      bf00            nop
Children
No data