[XviD-devel] Ansi C and porting to embedded tool chains
Rick Foos
xvid-devel@xvid.org
Fri, 22 Nov 2002 12:06:27 -0600
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C2921F.9597A4E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I'm trying to use xvidcore for embedded benchmarking. I need to be able =
to compare ansi C vs. all-out optimized on a wide range of embedded tool =
chains and platforms. The starting point is gcc and VC on Windows, =
Linux, and Solaris hosts. I then go to a number of embedded targets.
I'm working at the examples level, but I'd like to suggest, request or =
submit some 'New Developer' level of changes so that I can stay in sync =
with the source tree. In my experience these would benefit anyone =
porting xvid to embedded.=20
There are a number of trivial changes needed (like // vs. /* */ =
comments), and BSWAP - CACHE_LINESIZE 0 for no architecture. I need them =
to get the number of warnings down, and build without an architecture =
for an ansi C.=20
I have a CVS checkout, and am glad that the source tree is moving =
forward. My problem is that it's going to be too time consuming to merge =
future changes.=20
I use these GCC warning options, so you can see the extent of the =
problem, and it's trivial nature to fix:
WARNING_OPTIONS =3D \
-ansi -pedantic -Wcomment -fno-asm -fsigned-char \
-W -Wparentheses \
-Wreturn-type -Wswitch -Wunused \
-Wsign-compare -Wimplicit -Wreturn-type \
-Wshadow -Wpointer-arith -Wwrite-strings \
-Wsign-compare -Wstrict-prototypes -Wmissing-prototypes \
-Wmissing-declarations
The options are a bit strict, but it really minimizes nasty debug =
problems when a more primitive tool chain emits the wrong code. (and =
yes, I have seen nested comments emit code on some tools so I -Wcomment =
too)
Is there a way I could submit changes to the tree along these lines for =
integration into the source tree? The change wouldn't impact the code.
I'd be willing to do the changes, and if you could tell me the current =
set of tests needed would make sure I didn't mess anything up. ( I =
didn't see an xvidcore test other than cactus, xvid_encraw/xvid_decraw )
Best Regards,
Rick Foos
------=_NextPart_000_0005_01C2921F.9597A4E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm trying to use xvidcore for embedded =
benchmarking. I need to be able to compare ansi C vs. all-out=20
optimized on a wide range of embedded tool chains and platforms. =
</FONT><FONT=20
face=3DArial size=3D2>The starting point is gcc and VC on Windows, =
Linux, and=20
Solaris hosts. I then go to a number of embedded targets.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm working at the examples level, but =
I'd like to=20
suggest, request or submit some 'New Developer' level of changes so that =
I can=20
stay in sync with the source tree. In my experience these would benefit =
anyone=20
porting xvid to embedded. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There are a number of trivial changes =
needed (like=20
// vs. /* */ comments), and BSWAP - CACHE_LINESIZE 0 for no =
architecture. I=20
need them to get the number of warnings down, and build without an=20
architecture for an ansi C. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have a CVS checkout, and am glad =
that the=20
source tree is moving forward. My problem is that it's going to =
be too=20
time consuming to merge future changes. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I use these GCC warning options, so you =
can see the=20
extent of the problem, and it's trivial nature to fix:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>WARNING_OPTIONS =3D =20
\<BR> -ansi -pedantic =
-Wcomment=20
-fno-asm -fsigned-char \<BR> =
-W=20
-Wparentheses =
\<BR> =20
-Wreturn-type -Wswitch -Wunused =
\<BR> =20
-Wsign-compare -Wimplicit -Wreturn-type=20
\<BR> -Wshadow -Wpointer-arith =
-Wwrite-strings =20
\<BR> -Wsign-compare=20
-Wstrict-prototypes -Wmissing-prototypes=20
\<BR> =20
-Wmissing-declarations</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The options are a bit strict, but it =
really=20
minimizes nasty debug problems when a more primitive tool =
chain emits=20
the wrong code. (and yes, I have seen nested comments emit code on some =
tools so=20
I -Wcomment too)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Is there a way I could submit changes =
to the tree=20
along these lines for integration into the source tree? The change =
wouldn't=20
impact the code.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'd be willing to do the changes, and =
if you could=20
tell me the current set of tests needed would make sure I didn't mess =
anything=20
up. ( I didn't see an xvidcore test other than cactus,=20
xvid_encraw/xvid_decraw )</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Best Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Rick =
Foos<BR></FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01C2921F.9597A4E0--