On 19/09/13 19:13, Sebastian Macke wrote:
Hi Joern,
I am not sure to which ISO-C you refer to but if almost nothing happened
the last 14-23 years to solve this issue I am not sure if I am willing
to wait additional 20 years. Possibly I have to wait until C is obsolete.
Hi Sebastian,
I've copied Joern - I don't think he routinely reads this list.
Will you be at ORCONF next month? It would be good to discuss your ideas
for a better ABI there.
Best wishes,
Jeremy
As a reminder, I am talking about such a code construct
-------------------------
void f(int a, int b, int c){/*Do something with a,b and c*/}
......
typedef void (*Genericf)(int a, ....);
Genericf g = (Genericf)f;
g(1, 2, 3); /* <- Crash on OpenRISC because of different calling
conventions for variadic functions. */
-------------------------
The debugging of crashing programs because of such code constructs is
very difficult. There is no easy way to find such code. And even gcc
used such constructs internally. I have checked around 10 architectures
in gcc, and none of them differ between variadic functions and ordinary
functions.
I would suggest to leave the argument passing for non-variadic functions
alone; you can get variadic functions to use the same argument passing
rules by keeping track of the arguments from saved registers with a
separate
counter. FWIW, this is mandatory for targets that use different register
classes for different argument types (using separate counters for
separate
casses in that case), e.g. SH4.
At the moment I am leaving the argument passing for ordinary functions
alone except for the splitting of arguments. This makes the
implementation in gcc much easier as we can use the built-in functions
for va_start and va_arg (these function are implementing a counter).
So we can discuss about this little detail. At the moment I don't see
any cons about the splitting.
Sebastian
On 16/09/2013 12:51 PM, Joern Rennecke wrote:
Quoting Jeremy Bennett <[email protected]>:
On 13/09/13 01:28, Sebastian Macke wrote:
For me there are two solutions available
1. We can fight the endless war against the whole C-community, tell
them
that they are not following the C specification and patch every single
program out there to be able to run it on the or1k processor.
Well, as pre-ISO C is more and more replaced with ISO C and C++, these
issues tend to be addressed. Not necessarily at the speed you'd like,
though.
2. Change our ABI.
Hi Sebastian,
2 seems pragmatic. I've copied Joern Rennecke, who worked on the GCC
compiler a couple of years ago, but who doesn't regularly read the
list, in case he has some comments.
I would suggest to leave the argument passing for non-variadic functions
alone; you can get variadic functions to use the same argument passing
rules by keeping track of the arguments from saved registers with a
separate
counter. FWIW, this is mandatory for targets that use different register
classes for different argument types (using separate counters for
separate
casses in that case), e.g. SH4.
_______________________________________________
Openrisc mailing list
[email protected]
http://lists.opencores.org/listinfo/openrisc
_______________________________________________
Openrisc mailing list
[email protected]
http://lists.opencores.org/listinfo/openrisc
--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email: [email protected]
Web: www.embecosm.com
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
