| --- Log opened Tue Jul 16 00:00:29 2013 | ||
| poke53281 | The problem is this: On the OR1K we never split arguments between registers and memory. | 00:02 |
|---|---|---|
| poke53281 | Now I have messed up the ABI completely. | 01:17 |
| poke53281 | The ABI specification | 01:17 |
| stekern | ah, yes, so you have to check the args for > 32 bit, right? | 02:18 |
| stekern | my linux in qemu session had also crashed during the night | 02:20 |
| poke53281 | Well, my solution is at the moment, to allow parameters to be split. | 03:12 |
| poke53281 | it seems not a big deal in the source. Well, the torture test will show | 03:15 |
| stekern | yeah, I can't think of a way to get the vararg handling to know what type the parameters are | 04:25 |
| poke53281 | Second parameter of va_arg gives you the type. So I can keep the current versioin and write my own handlers for va_arg and va_start. But this is the more complex solution. | 04:30 |
| stekern | hmm, yeah | 04:35 |
| stekern | is it the default va_arg and va_start handlers that assume that your arguments are on the stack? | 04:36 |
| stekern | i.e. if you wrote your own handlers, you wouldn't need the "save your regs to stack" workaround? | 04:36 |
| poke53281 | problem is that the 8byte data types must be separated into two registers. The current ABI says, that if there is only register left that this type is completely saved on the stack. But the current saveargs-handler cannot handle such a case, because it don't know. | 04:39 |
| poke53281 | There are several options to handle varargs. But this is the easiest one. | 04:40 |
| poke53281 | And done by most architectures | 04:41 |
| poke53281 | I have to break the ABI anyhow. | 04:42 |
| poke53281 | But this is also a rare case- You need a function like this: f(int a, double b, double c, double d) | 04:44 |
| poke53281 | According to the ABI d is saved on the stack. But I need it separated to register and stack. | 04:45 |
| stekern | yeah, I understand the problem, that wasn't the question | 04:49 |
| poke53281 | It is not necessary to break that part of the ABI. But it would mean to add a lot more code to gcc and additional tests. | 04:57 |
| stekern | still not an answer to my question ;) | 04:59 |
| stekern | I'm wondering where the assumption in gcc is that arguments are on the stack in varargs functions | 05:00 |
| stekern | I can look for myself if you don't now, no worries ;) | 05:00 |
| stekern | *know | 05:02 |
| poke53281 | I don't know the details. va_start needs the last argument before varargs region. | 05:02 |
| stekern | mmm, in LLVM we lower the va_start like this: https://github.com/openrisc/llvm-or1k/blob/master/lib/Target/OR1K/OR1KISelLowering.cpp#L875 | 05:11 |
| poke53281 | Puhh, difficult to understand whats going on there. I can search for the stand va_args handler in gcc. | 05:20 |
| poke53281 | But I like the syntax. Finally C++ | 05:21 |
| stekern | I'm no huge c++ fan, but it's used with caution in llvm | 05:24 |
| stekern | and yes, llvm is a bit intimidating at first sight, but when you get under the skin of it, you'll find it very logical and straight forward | 05:26 |
| poke53281 | c++ gives you all options you can think of. It depends what you do with it. I have seen terrible code in c++ heavily depending on template meta-programming. It makes everything unreadable. But you can write also very clean code which is much better than C. | 05:35 |
| stekern | I agree, and you can of course abuse C in unholy ways too | 05:46 |
| stekern | and c++ has it place and uses, but I've noticed that when c isn't the tool for the job I usually don't resort to c++ first hand | 05:54 |
| stekern | (given I have a choice) ;) | 05:54 |
| poke53281 | One of the most important aspects of the software I am writing is speed. So Intel defines basically my choice C/C++/Fortran. | 06:01 |
| stekern | can't say Fortran would be my first choice neither, but that's more because of lack of experience ;) | 06:08 |
| poke53281 | Fortran is mainly for the softfware programmed in the 60s and 70s on punchcards. They are still used and well tested. No wants to rewrite them. Normally no wants should start a new project in Fortran nowadays. But Fortran 90 has similar options in comparison to C. So you can. | 06:10 |
| stekern | yeah, I know, and that's partly why I have no experience in it, I have little practical use for it. | 06:11 |
| poke53281 | Fortran had natice complex number support 30 years before C. | 06:12 |
| poke53281 | native | 06:12 |
| poke53281 | Today the testsuite crashed around 5 times. Maybe I will try an older kernel tomorrow. | 06:19 |
| poke53281 | Linux crashed on or1ksim without any message I mean | 06:20 |
| stekern | I'm still on the 3.8 kernel in my "testsuite" setup | 06:20 |
| stekern | but I had one similar crash on that setup too | 06:20 |
| stekern | would be interesting to figure out what happens | 06:21 |
| poke53281 | There is still this warning message during boot. You see the stack trace. | 06:21 |
| poke53281 | An interrupt is not disabled at a certain point. | 06:21 |
| stekern | yeah, I know, I have posted a patch to lkml that fixes that | 06:21 |
| stekern | https://lkml.org/lkml/2013/4/29/111 | 06:23 |
| stekern | maybe I should poke Jonas about it... | 06:24 |
| poke53281 | I thought Jonas is the maintainer and you should send the patches to him. | 06:25 |
| stekern | yes, the openrisc list was CC:ed on that mail | 06:28 |
| stekern | the linux openrisc list that is | 06:28 |
| stekern | so the patch is for him to take, but that doesn't mean others should be able to comment on it | 06:31 |
| stekern | should *not* be able to comment on it | 06:31 |
| stekern | bad structure in that sentence, but you get my point ;) | 06:32 |
| stekern | this is odd, without the ramstyle attribute, this code doesn't get inferred as RAM: http://pastie.org/8145028 | 07:20 |
| stekern | it's on cyclone III | 07:20 |
| stekern | and no warning or messages about it | 07:21 |
| juliusb | stekern: why the VHDL? I missed that.... | 14:58 |
| -!- mboehnert2 is now known as hauslude | 15:07 | |
| stekern | juliusb: oh, it's dayjob related | 16:11 |
| -!- Netsplit *.net <-> *.split quits: simoncook | 17:07 | |
| -!- Netsplit over, joins: simoncook | 17:10 | |
| -!- Netsplit *.net <-> *.split quits: jonmasters, LoneTech | 17:35 | |
| -!- Netsplit *.net <-> *.split quits: Amadiro, trem, heroux, blueCmd, LoneTech_, olofk, jakob_, poke53281, trevorman, forkG, (+2 more, use /NETSPLIT to show all of them) | 22:43 | |
| --- Log closed Wed Jul 17 00:00:30 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!