IRC logs for #openrisc Tuesday, 2013-07-16

--- Log opened Tue Jul 16 00:00:29 2013
poke53281The problem is this: On the OR1K we never split arguments between registers and memory.00:02
poke53281Now I have messed up the ABI completely.01:17
poke53281The ABI specification01:17
stekernah, yes, so you have to check the args for > 32 bit, right?02:18
stekernmy linux in qemu session had also crashed during the night02:20
poke53281Well, my solution is at the moment, to allow parameters to be split.03:12
poke53281it seems not a big deal in the source. Well, the torture test will show03:15
stekernyeah, I can't think of a way to get the vararg handling to know what type the parameters are04:25
poke53281Second 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
stekernhmm, yeah04:35
stekernis it the default va_arg and va_start handlers that assume that your arguments are on the stack?04:36
stekerni.e. if you wrote your own handlers, you wouldn't need the "save your regs to stack" workaround?04:36
poke53281problem 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
poke53281There are several options to handle varargs. But this is the easiest one.04:40
poke53281And done by most architectures04:41
poke53281I have to break the ABI  anyhow.04:42
poke53281But this is also a rare case- You need a function like this: f(int a, double b, double c, double d)04:44
poke53281According to the ABI d is saved on the stack. But I need it separated to register and stack.04:45
stekernyeah, I understand the problem, that wasn't the question04:49
poke53281It 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
stekernstill not an answer to my question ;)04:59
stekernI'm wondering where the assumption in gcc is that arguments are on the stack in varargs functions05:00
stekernI can look for myself if you don't now, no worries ;)05:00
poke53281I don't know the details. va_start needs the last argument before varargs region.05:02
stekernmmm, in LLVM we lower the va_start like this:
poke53281Puhh, difficult to understand whats going on there. I can search for the stand va_args handler in gcc.05:20
poke53281But I like the syntax. Finally C++05:21
stekernI'm no huge c++ fan, but it's used with caution in llvm05:24
stekernand 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 forward05:26
poke53281c++ 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
stekernI agree, and you can of course abuse C in unholy ways too05:46
stekernand 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 hand05:54
stekern(given I have a choice) ;)05:54
poke53281One of the most important aspects of the software I am writing is speed. So Intel defines basically my choice C/C++/Fortran.06:01
stekerncan't say Fortran would be my first choice neither, but that's more because of lack of experience ;)06:08
poke53281Fortran 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
stekernyeah, I know, and that's partly why I have no experience in it, I have little practical use for it.06:11
poke53281Fortran had natice complex number support 30 years before C.06:12
poke53281Today the testsuite crashed around 5 times. Maybe I will try an older kernel tomorrow.06:19
poke53281Linux crashed on or1ksim without any message I mean06:20
stekernI'm still on the 3.8 kernel in my "testsuite" setup06:20
stekernbut I had one similar crash on that setup too06:20
stekernwould be interesting to figure out what happens06:21
poke53281There is still this warning message during boot. You see the stack trace.06:21
poke53281An interrupt is not disabled at a certain point.06:21
stekernyeah, I know, I have posted a patch to lkml that fixes that06:21
stekernmaybe I should poke Jonas about it...06:24
poke53281I thought Jonas is the maintainer and you should send the patches to him.06:25
stekernyes, the openrisc list was CC:ed on that mail06:28
stekernthe linux openrisc list that is06:28
stekernso the patch is for him to take, but that doesn't mean others should be able to comment on it06:31
stekernshould *not* be able to comment on it06:31
stekernbad structure in that sentence, but you get my point ;)06:32
stekernthis is odd, without the ramstyle attribute, this code doesn't get inferred as RAM:
stekernit's on cyclone III07:20
stekernand no warning or messages about it07:21
juliusbstekern: why the VHDL? I missed that....14:58
-!- mboehnert2 is now known as hauslude15:07
stekernjuliusb: oh, it's dayjob related16:11
-!- Netsplit *.net <-> *.split quits: simoncook17:07
-!- Netsplit over, joins: simoncook17:10
-!- Netsplit *.net <-> *.split quits: jonmasters, LoneTech17: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 2.15.2 by Marius Gedminas - find it at!