Conversation Between Blah and Kimonas
1 to 15 of 17
  1. Blah
    March 9th, 2016 2:17 PM
    Blah
    generally if they set R0 before popping, and don't pop R0, that means they have a return value. I think those functions would return an exit status to determine success or failure, so it returning 0 must be in the case of successful execution with valid parameters.
  2. Kimonas
    March 9th, 2016 12:55 PM
    Kimonas
    Also, functions flag_set and clear set the r0 to 0 before they exit. Does that mean that they have a return value which will always(?) be zero?
  3. Blah
    March 9th, 2016 11:42 AM
    Blah
    Flags are in save block 1. You can use the set, clear and check flags to be manipulating them. There's a function called flag_access which you can use to try and figure out their addresses. That said, flags are sequential bits, so it probably won't be a good idea to directly try to edit them as with variables.
  4. Kimonas
    March 9th, 2016 11:31 AM
    Kimonas
    Also, I have a question regarding C. I want to play a little bit around with flags. I found the functions flag_set and flag_check from knizz's database and added them on the .ld file. But my question is, where are the addresses of flags?
  5. Kimonas
    March 9th, 2016 11:29 AM
    Kimonas
    Ooooh I see. So the file/template is now changed on github? And thanks :D
  6. Blah
    March 8th, 2016 3:04 PM
    Blah
    I helped SphericalIce with the same issue earlier. I think you downloaded the template before the alternative versions were pushed in git. Great that you figured it out though :D
  7. Kimonas
    March 8th, 2016 11:31 AM
    Kimonas
    Fixed it, in the end I was the stupid one :p. Had to add also C:\devkitPro\devkitARM\arm-none-eabi\bin to the PATH.
  8. Kimonas
    March 8th, 2016 10:27 AM
    Kimonas
    There are 4 files inside build, two with random numbers names and a linked.o and output files. It must be some stupid error with windows or something. I'm gonna also try it on my linux just to make sure. Thanks for the help tho
  9. Blah
    March 8th, 2016 9:58 AM
    Blah
    You ran build before this, correct? Make sure you have files inside the newly created bin folder
  10. Kimonas
    March 8th, 2016 8:53 AM
    Kimonas
    Tried it and gave me a different error, but had also to do with the OBJDUMP.



    I tried reinstalling devkitPro, but still da same :/
  11. Blah
    March 8th, 2016 8:21 AM
    Blah
    Try doing "python scripts\insert2 --debug"
  12. Kimonas
    March 8th, 2016 8:16 AM
    Kimonas
    Hey there FBI, could help me with an issue I have? I was following the tutorial you wrote for C, I installed python 3.5, devkitPro and fixed the slashes in the System's Variables. Also the "python scripts\build" command from the terminal works fine but when I hit the "python scripts\insert --debug" it gives me the following errors:



    It says that OBJDUMP is not recognized as an internal or external command. Do you have any ideas why this is happening or how can I fix it?
  13. Blah
    February 11th, 2016 11:57 AM
    Blah
    not exactly. The stack pointer has a fixed amount of space, it doesn't call malloc. Also, using malloc for function parameters means you'll need to free to used memory afterwards.

    Anyways, this is how it is done by convention/design. So..yeah :P
  14. Kimonas
    February 11th, 2016 11:41 AM
    Kimonas
    I see. Couldn't we achieve that by using the ram and malloc, or even the rom?

    For example we'd first use malloc to get an address that has space for, lets say, 12 bytes, store the value of the 3 parameter registers in the appropriate addresses and then call our function with one argument, the pointer to that address in the ram?

    Actually now that I think of it, isn't this what stack pointer does? :P
  15. Blah
    February 11th, 2016 11:13 AM
    Blah
    malloc takes an int size arguement in R0, and returns a pointer to free RAM space in R0.

    Memcpy takes a pointer to the destination in r0, a pointer to the source in r1 and the size of the data of the source in r2. It will copy the contents in r1 to the pointer at r0.

    By convention and standard, when calling a function, r0-r3 contain paramaters to the function. However, you will find functions with more than 4 paramaters, as such r0-r3 are not enough. In this case, the stack pointer is used instead to hold said paramaters. That is why you'll see sometimes functions writing to the SP before another function call. Sometimes functions will also use the SP as a small amount of free temporary RAM for their local variables and such.