Re: [Mspgcc-users] ABI problem?
- Ursprüngliche Nachricht - Von: Peter Bigot Gesendet am: 07 Okt 2010 20:21:49 Third time's the charm? It's been so long since I've dealt with KR C I've forgotten the rules. The behavior is correct. char and short are upcast to int when no declaration is in scope. Integral types that are larger than int are left as is. That you're masking off all but the low byte does not change the type of the expression that's used as a parameter: it's a 32-bit int on a 16-bit microcontroller, and requires two registers to pass by value. No bug here. Either explicitly cast to int, or make sure there's a declaration in scope so the compiler knows what to do. I suggest the latter. I always wondered why mspgcc does it this way. It comes down to the little/big endian discussion. The main advantage of little endianess is, that the first byte contrains the LSB, no matter how large the datatype is. So if you need the LSB only, just take the first byte and you're done. Unfortunately, GCC was developed by people who obviously favorized big endianess. And therefore R15 does not hold the lower word of a parameter, if the parameter exceeds 16 bit, it holds the upper 16 bits, so the meaning of R15 changes and the callee may be hosed. I wonder why a byte parameter is passed in the lower byte of R15 and not the upper one by this logic. :) My intuitive assumption was, that R15 would hold a short parameter as well as the lower word of a long parameter and I was surprised to learn that id doesn't. It makes passing return parameters from one funciton to another more difficult (requiring moves when typecasting). But well, it is as it is. JMGross -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] ABI problem?
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
That's not an ABI problem. Without a declaration available at the point of
call, C mandates that the parameter be assumed to be an int (two bytes). If
you define a function with non-int parameters, you have to have a compatible
declaration in scope wherever it's invoked. Using to mask off bits, or
even casting the parameter, won't do any good.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
Hi Kim,
On Thu, 7 Oct 2010 08:26:15 -0400
Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
That seems to be your problem. At the time the compiler compiles
file2.c it doesn't know anything about bytefunc so it assumes its
declaration is int bytefunc (int arg). If you enabled warnings (-Wall)
you could see the compiler complaining about that.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
That's one way to solve it, but it is a bit tedious and not very clean.
Better, define a header file with your forward declarations and include
that one in file2.c.
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
Regards,
Hans
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
So does that mean that calling a function which takes an int with a byte
won't work? Or, alternatively, that calling a function with a byte that
expects an int won't work? Because, in my experience that does seem to
work. Maybe I haven't run across the problem in other contexts, though.
I expected the long to be shortened to int before the call, so that it would
be in R15. The confusing part was when it passed the lower portion in R14
instead.
On Thu, Oct 7, 2010 at 8:42 AM, Peter Bigot p...@peoplepowerco.com wrote:
That's not an ABI problem. Without a declaration available at the point of
call, C mandates that the parameter be assumed to be an int (two bytes).
If
you define a function with non-int parameters, you have to have a
compatible
declaration in scope wherever it's invoked. Using to mask off bits, or
even casting the parameter, won't do any good.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the
calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
Sorry, you're right: I read this too quickly.
I don't think it's an ABI problem so much as a compiler problem: it's
actually passing the 32-bit value in registers r14 and r15, instead of
truncating it to an int and passing it in r15, as it's supposed to do when
there's no declaration.
Fine. Yet another bug to fix.
Still, work around is to properly declare the function. Then you can pass
it as a uint32_t, int, or uint8_t, whatever you want.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
Third time's the charm? It's been so long since I've dealt with KR C I've
forgotten the rules.
The behavior is correct. char and short are upcast to int when no
declaration is in scope. Integral types that are larger than int are left
as is. That you're masking off all but the low byte does not change the
type of the expression that's used as a parameter: it's a 32-bit int on a
16-bit microcontroller, and requires two registers to pass by value.
No bug here. Either explicitly cast to int, or make sure there's a
declaration in scope so the compiler knows what to do. I suggest the
latter.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] ABI problem?
OK, thanks. Good to know. I'll go back and put a bookmark in my KR :-)
On Thu, Oct 7, 2010 at 2:21 PM, Peter Bigot p...@peoplepowerco.com wrote:
Third time's the charm? It's been so long since I've dealt with KR C I've
forgotten the rules.
The behavior is correct. char and short are upcast to int when no
declaration is in scope. Integral types that are larger than int are left
as is. That you're masking off all but the low byte does not change the
type of the expression that's used as a parameter: it's a 32-bit int on a
16-bit microcontroller, and requires two registers to pass by value.
No bug here. Either explicitly cast to int, or make sure there's a
declaration in scope so the compiler knows what to do. I suggest the
latter.
Peter
On Thu, Oct 7, 2010 at 7:26 AM, Kim Toms kim.t...@gmail.com wrote:
I had a function which took a byte argument and returned a byte. From
another file (compiled into a separate object), I called the function
without first declaring it. The calling function used an argument which
evaluated to uint32_t.
In the called function, it looked for the argument in R15. In the
calling
function, it left the low byte of the argument in R14.
Declaring the called function fixed the problem. Here's an example:
file1.c:
uint8_t bytefunc(uint8_t arg)
{ ...
}
file2.c:
extern uint8_t bytefunc(uint8_t); // this line required to make the ABI
generate the correct code
main()
{
uint32_t i = 123456;
bytefunc(i 0xFFL);
}
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
