| -!- Jia` is now known as Jia | 05:55 | |
| -!- maximi89__ is now known as maximi89 | 08:44 | |
| stekern | morning | 08:46 |
|---|---|---|
| stekern | I've noticed that the arch manual is a bit unclear on how structs should be returned | 08:47 |
| stekern | it only states that the pointer to the struct should be in r11 | 08:48 |
| stekern | but that's not exactly the whole truth | 08:58 |
| stekern | if I have understood correctly, this is how it works (in gcc): the caller function allocates stack for the struct, and passes a pointer to the callee function in r3, the callee function then copies the struct content to this memory area | 09:01 |
| stekern | so what's the r11 actually for? | 09:01 |
| stekern | since the caller function already has the pointer to the struct (it's in r3) | 09:02 |
| Jia | the code in gcc is mess, too, and, I'm not sure about this part | 09:05 |
| stekern | I haven't actually looked at the code, just the generated asm | 09:10 |
| stekern | but it sounds to me that copying the value to r11 is completely redundant, and just put there to "keep it consistent" | 09:11 |
| Jia | keep it simple and teach me :-) | 09:13 |
| stekern | llvm does it like this "out of the box" as well, but naturally, it doesn't copy the value to r11. I'm tempted to leave it as it is. | 09:31 |
| stekern | s/value/pointer | 09:32 |
| jeremybennett | stekern: It depends on the size of the struct. | 10:22 |
| jeremybennett | Small ones can be returned by value. | 10:23 |
| jeremybennett | You'd need to check with amylaar, but I think up to 32 bits in r11 and up to 64 bits in r11/r12. | 10:24 |
| jeremybennett | There are some other constraints as well I think. | 10:25 |
| jeremybennett | But you are right, it should be documented. | 10:25 |
| stekern | jeremybennett: ok, so it is even less compliant with what the arch manual is saying? | 10:25 |
| stekern | since it is stating that a *pointer* to the struct is returned in r11 | 10:25 |
| jeremybennett | I think that when the value is returned in memory, then it will also return a pointer to that memory in r11. | 10:26 |
| jeremybennett | I'm doing this from memory - I may be wrong about the small values. | 10:26 |
| jeremybennett | amylaar is the expert, and he'll have taken the existing ABI when the manual doesn't document things. | 10:27 |
| stekern | yeah, but giving the pointer in r11 gives no extra value, since the pointer is already in r3 (if I'm not missing anything) | 10:27 |
| stekern | I'll check the small values | 10:28 |
| jeremybennett | Yes - there may be advantages to having the value returned as well (r3 is not callee saved). | 10:28 |
| stekern | ok, may be, but the caller will probably just save r3 on the stack and use that | 10:30 |
| jeremybennett | That would be inefficient - accessing main memory. Let the compiler guarantee the value will be in r11. The worst case is that the value is saved on the stack and restored (same as you doing it). Best case it is a register move. | 10:31 |
| stekern | small values go by pointer as well | 10:37 |
| stekern | worst case it is save-restor _and_ register move ;) | 10:40 |
| jeremybennett | stekern: Unlikely though - GCC gets that right with anything above -O0. | 10:41 |
| stekern | but you're probably right, if nothing else, putting the value in r11 will prevent bug-bites later on | 10:41 |
| jeremybennett | stekern: And you are right that this part of the ABI should be documented! | 10:42 |
| stekern | jeremybennett: (> -O0) nah, it doesn't | 10:44 |
| stekern | it still store-load r3 | 10:44 |
| stekern | ah, no sorry I was too quick, it's just using the frame-pointer | 10:52 |
| stekern | since it is on it's own stack | 10:52 |
| stekern | I still don't think r11 ever will be used | 10:53 |
| stekern | perhaps if the stack offset is larger than what fits in the imm of a load? | 10:54 |
| stekern | nope, then it just use the scavenged offset register | 10:58 |
| jeremybennett | I'm seeing Joern (amylaar) shortly - I'll ask him about it. | 10:59 |
| stekern | yeah, do so, I'll still put a copy into r11, don't worry ;) | 11:00 |
| stekern | I'd be happy to see a case where it'd be used though | 11:01 |
| maximi89 | stekern, have you heard of coreboot? | 13:11 |
| stekern | maximi89: yes, I've heard about it, not particularly familiar with it though, why? | 13:13 |
| maximi89 | stekern, just curious of getting a hardware entire created with open specifications, like the raspberry | 13:19 |
| stekern | hmm, yeah sure... but isn't coreboot (mostly) x86? | 13:23 |
| stekern | you know that we have u-boot support for openrisc? | 13:23 |
| maximi89 | something you told me the other day | 13:23 |
| maximi89 | my router use uboot | 13:24 |
| maximi89 | as far as I know | 13:24 |
| maximi89 | with OpenWRT | 13:24 |
| stekern | I don't recall telling you that the other day | 13:25 |
| maximi89 | does this project use uclinux? | 13:25 |
| maximi89 | in some devices? | 13:25 |
| stekern | no, linux | 13:25 |
| maximi89 | directly :O | 13:26 |
| maximi89 | RISC it's a type of work of the logical gates or the arquitecture? or it applies for both? | 13:28 |
| stekern | http://en.wikipedia.org/wiki/Reduced_instruction_set_computing | 13:28 |
| maximi89 | yeah i am reading xd | 13:28 |
| maximi89 | the instruction supported by the old RISC specified there are the ASM code right? | 13:36 |
| stekern | hmm, what? | 13:37 |
| maximi89 | the "instruction" who talk the wiki are the assembler code supported by that chips am right? | 13:38 |
| stekern | err, still not quite get what you are asking... instructions are instructions, assembler code is a way to express a list of instructions in a human readable form | 13:40 |
| maximi89 | thanks | 13:40 |
| maximi89 | more clear | 13:41 |
| maximi89 | time to sleep, back tomorrow 7am here XD | 13:44 |
| maximi89 | good night | 13:45 |
| stekern | night | 13:47 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!