Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Sat May 25, 2013 11:31 pm

View unanswered posts | View active topics View unread posts


Board index » SGI » SGI: Development

All times are UTC - 8 hours


Forum rules


Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.



Post new topic Reply to topic  Page 1 of 3
  [ 43 posts ]  Go to page 1, 2, 3  Next
  Print view Previous topic | First unread post | Next topic 
Author Message
Oskar45
 Post subject: Python 2.5.2
Unread postPosted: Fri May 09, 2008 1:26 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
I recently started to compile under 6.5.30/MipsPro 7.4.4 a huge package which also includes Python 2.5.1. Unfortunately, I ran into some compiling problems which got me stuck. Therefore, I downloaded neko_python-2.4.1 and re-compiled the source [no problems there, just a bunch of warnings] to cross-check. Sadly, it turned that the problems I've are in pieces of code added after the release of Python 2.4.1.

So, has anyone successfully compiled Python 2.5.1 w/MipsPro 7.4.4 and could give me some help? And a neko_2.5.1.tardist would be fine, then...
Top
 Profile  
 
Oskar45
Unread postPosted: Mon May 19, 2008 1:19 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
Seems gcc can handle this without problems:

Code:
/* O32 stack frames have 32bit integer args */
typedef unsigned int     ffi_arg __attribute__((__mode__(__SI__)));
typedef signed   int     ffi_sarg __attribute__((__mode__(__SI__)));
#else
/* N32 and N64 frames have 64bit integer args */
typedef unsigned int     ffi_arg __attribute__((__mode__(__DI__)));
typedef signed   int     ffi_sarg __attribute__((__mode__(__DI__)));


However CC complains about it with expecting semi-colons after ffi_arg/ffi_sarg. Any hints of how to recode that for MipsPro?

Thanks.
/oskar
Top
 Profile  
 
porter
Unread postPosted: Mon May 19, 2008 3:55 am 
Offline
User avatar

Joined: Wed Nov 01, 2006 10:37 pm
Posts: 2879
Location: NZ
Where is this code from? Is it GCC specific? I doesn't look like ANSI.

In terms of what it is saying in the comments, it is true that both N32 and 64 bit architectures arguments are promoted to 64 bits, where as O32, int and below are still 32bit.

If you are reading variable argument lists then use the compiler provided stdargs.h, if you are constructing variable argument lists on the fly (and it can be done) then you have to worry about the size and alignment yourself.

_________________
:Indy: :Indigo2IMP: :Octane: :Indy: 4xRS6K 2xHP9K 6xSUN 1xDEC 14xMAC 7xPC 2xPS2
Top
 Profile  
 
jan-jaap
Unread postPosted: Mon May 19, 2008 4:01 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3578
Location: Wijchen, The Netherlands
porter wrote:
Is it GCC specific?

Yes: http://gcc.gnu.org/onlinedocs/gcc-4.3.0 ... butes.html

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)
Top
 Profile  
 
Oskar45
Unread postPosted: Mon May 19, 2008 4:09 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
The code comes from Python 2.5.1/2.5.2, in the Foreign Function Interface part...

Seems like there's no way to get MipsPro working with that?
Top
 Profile  
 
porter
Unread postPosted: Mon May 19, 2008 4:15 am 
Offline
User avatar

Joined: Wed Nov 01, 2006 10:37 pm
Posts: 2879
Location: NZ
Oskar45 wrote:
Seems like there's no way to get MipsPro working with that?


Sure

Code:
#ifdef __GNUC__
#ifdef _ABI_O32_OR_WHATEVER_
/* O32 stack frames have 32bit integer args */
typedef unsigned int     ffi_arg __attribute__((__mode__(__SI__)));
typedef signed   int     ffi_sarg __attribute__((__mode__(__SI__)));
#else
/* N32 and N64 frames have 64bit integer args */
typedef unsigned int     ffi_arg __attribute__((__mode__(__DI__)));
typedef signed   int     ffi_sarg __attribute__((__mode__(__DI__)));
#endif
#else
do the thing according to ANSI coding conventions remembering that this is supposed to be C code and not a Richard Stallman Special
#endif

_________________
:Indy: :Indigo2IMP: :Octane: :Indy: 4xRS6K 2xHP9K 6xSUN 1xDEC 14xMAC 7xPC 2xPS2
Top
 Profile  
 
Oskar45
Unread postPosted: Mon May 19, 2008 6:13 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
Poking around more, I found this at http://www.hiit.fi/files/fi/da/libffi/ffi_common.h:

Code:
/* Terse sized type definitions.  */
#if defined(__GNUC__) || defined(__GCCE__)

typedef unsigned int UINT8  __attribute__((__mode__(__QI__)));
typedef signed int   SINT8  __attribute__((__mode__(__QI__)));
typedef unsigned int UINT16 __attribute__((__mode__(__HI__)));
typedef signed int   SINT16 __attribute__((__mode__(__HI__)));
typedef unsigned int UINT32 __attribute__((__mode__(__SI__)));
typedef signed int   SINT32 __attribute__((__mode__(__SI__)));
typedef unsigned int UINT64 __attribute__((__mode__(__DI__)));
typedef signed int   SINT64 __attribute__((__mode__(__DI__)));

#elif defined(_MSC_VER)

typedef unsigned __int8  UINT8;
typedef signed __int8    SINT8;
typedef unsigned __int16 UINT16;
typedef signed __int16   SINT16;
typedef unsigned __int32 UINT32;
typedef signed __int32   SINT32;
typedef unsigned __int64 UINT64;
typedef signed __int64   SINT64;

#else
#error "Need typedefs here"
#endif


[it's missing from the ffi_common.h I've in the current Python 2.5.1]

Looks like that could do the trick... :?:

Edit: Actually, while it's indeed missing from libffi/ffi_common.h and also from the Mips/SGI related ffi_target.h [where I'd have neeed it most], it is indeed available in some other branch where I'd not cared to look before :oops:


Last edited by Oskar45 on Mon May 19, 2008 11:10 pm, edited 1 time in total.

Top
 Profile  
 
bplaa.yai
Unread postPosted: Mon May 19, 2008 7:46 am 
Offline
User avatar

Joined: Wed Mar 26, 2008 11:04 am
Posts: 302
Location: Paris
This thread makes me thinking again that it would be a good idea to create a wiki page / sticky thread where we could all share our tips & tricks in porting software to Irix / mipspro ? Instead of all of us having to dig arround for solving the same issues ?

For example, issues I had lately in compiling stuff on Irix :
Code:
     int size = 12;
     double tval[size];

should be replaced by
Code:
     int size = 12;
     double *tval;
     tval = new double[size];
     ...
     delete[] tval;


or

Code:
    va_copy(x, y);

by
Code:
    memcpy(x, y, sizeof(va_list));


... and so on ?

_________________
:Onyx2: :Fuel: :1600SW: :O2: :0300: :0300:
Top
 Profile  
 
porter
Unread postPosted: Mon May 19, 2008 9:15 am 
Offline
User avatar

Joined: Wed Nov 01, 2006 10:37 pm
Posts: 2879
Location: NZ
bplaa.yai wrote:
Code:
     int size = 12;
     double *tval;
     tval = new double[size];
     ...
     delete[] tval;


You would need to have a that in a destructor so if an exception gets thrown it is cleared up.

bplaa.yai wrote:
Code:
    va_copy(x, y);

by
Code:
    memcpy(x, y, sizeof(va_list));


Surely that should be

Code:
#define va_copy(a,b)        a=(b)


The only two platforms I know of that have complex va_lists are DEC Alpha and Linux on PowerPC.

_________________
:Indy: :Indigo2IMP: :Octane: :Indy: 4xRS6K 2xHP9K 6xSUN 1xDEC 14xMAC 7xPC 2xPS2
Top
 Profile  
 
stuart
Unread postPosted: Wed May 21, 2008 4:04 am 
Offline
User avatar

Joined: Mon Aug 23, 2004 4:37 pm
Posts: 911
Location: Cambridge, UK
This is a useful resource:

http://www.unixwiz.net/techtips/gnu-c-attributes.html

... and, as noted, __attribute__ are GNU-only advisory options which don't affect the code produced, only the warnings the compiler outputs (and thus breaking all other compilers to achieve this could be construed as somewhat rude at the very least...)

In any case, the solution to the problem is (at noted) to include:
Code:
/* If we're not using GNU C, elide __attribute__ */
#ifndef __GNUC__
#  define  __attribute__(x)  /*NOTHING*/
#endif
... in any code which includes this form of GNU-ism.
Top
 Profile  
 
Oskar45
Unread postPosted: Sun May 25, 2008 11:55 pm 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
stuart wrote:
This is a useful resource:

http://www.unixwiz.net/techtips/gnu-c-attributes.html

... and, as noted, __attribute__ are GNU-only advisory options which don't affect the code produced, only the warnings the compiler outputs (and thus breaking all other compilers to achieve this could be construed as somewhat rude at the very least...)

In any case, the solution to the problem is (at noted) to include:
Code:
/* If we're not using GNU C, elide __attribute__ */
#ifndef __GNUC__
#  define  __attribute__(x)  /*NOTHING*/
#endif
... in any code which includes this form of GNU-ism.


Hm, I'm not sure it's in general okay to ignore __attribute__ as per the above. Eg., in the example I'd cited above
Code:
/* O32 stack frames have 32bit integer args */
typedef unsigned int ffi_arg __attribute__((__mode__(__SI__)));
typedef signed int ffi_sarg __attribute__((__mode__(__SI__)));
#else
/* N32 and N64 frames have 64bit integer args */
typedef unsigned int ffi_arg __attribute__((__mode__(__DI__)));
typedef signed int ffi_sarg __attribute__((__mode__(__DI__)));

eliding it would break the code - the __mode__ certainly conveys important information about the types. In the O32 case, it would be fine to get rid of the __attribute__ and it would be ok. However, for the N32/64 case, you still have to take care about the DI mode and recode it:
Code:
typedef __uint64_t ffi_arg;
typedef __int64_t ffi_sarg;
Top
 Profile  
 
porter
Unread postPosted: Mon May 26, 2008 12:26 am 
Offline
User avatar

Joined: Wed Nov 01, 2006 10:37 pm
Posts: 2879
Location: NZ
gcc had a major mips n32 bug until about 3.4.3 where it did not generate correct code for parsing arguments, especially small structs and had to kludge inet_addr ()among others.

If your code depends on GCC'isms then it is most definitely not portable code.

_________________
:Indy: :Indigo2IMP: :Octane: :Indy: 4xRS6K 2xHP9K 6xSUN 1xDEC 14xMAC 7xPC 2xPS2
Top
 Profile  
 
Oskar45
Unread postPosted: Mon May 26, 2008 12:33 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
porter wrote:
If your code depends on GCC'isms then it is most definitely not portable code.

True, but I don't see any reason for not trying to recode GCCisms if there's a decent way [like in the above]...
Top
 Profile  
 
porter
Unread postPosted: Mon May 26, 2008 12:44 am 
Offline
User avatar

Joined: Wed Nov 01, 2006 10:37 pm
Posts: 2879
Location: NZ
Out of curiosity, when people manage workarounds or fixes as part of a port to IRIX, do people ever feed those changes back to the authors or maintainers of the original source?

If you do are the responses positive or negative? Especially if it is for a platform those people are unable to test on?

_________________
:Indy: :Indigo2IMP: :Octane: :Indy: 4xRS6K 2xHP9K 6xSUN 1xDEC 14xMAC 7xPC 2xPS2
Top
 Profile  
 
Oskar45
Unread postPosted: Mon May 26, 2008 11:30 am 
Offline
User avatar

Joined: Mon Dec 05, 2005 2:35 am
Posts: 1919
Location: Vienna, Austria
porter wrote:
Out of curiosity, when people manage workarounds or fixes as part of a port to IRIX, do people ever feed those changes back to the authors or maintainers of the original source?

If you do are the responses positive or negative? Especially if it is for a platform those people are unable to test on?

In two rather major ports to Irix/MipsPro, I'd worked closely with the authors to get it running [DDLAB & NIAL - I'd posted on them here then]. They were really quite positive about it. In another case, I pointed the author of the original even to a thread on Nekochan regarding some porting issues - and he was quite positive about it as well [although, as far as I can tell, he up to now hasn't fixed the issues I'd pointed out to him]. In a couple of other cases, while I'd told the author, I haven't got any response at all. Right now, I'm working on a mammoth project getting ported to MipsPro. Judging from previous correspondence, though, I'm sure that guy will most certainly appreciate my findings...
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 3
  [ 43 posts ]  Go to page 1, 2, 3  Next

Board index » SGI » SGI: Development

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group