porting from solaris i86 to solaris sparc

porting from solaris i86 to solaris sparc

Post by chik » Fri, 11 Sep 1998 04:00:00



Hi all,
    we are  planning to port a HUGE multithreaded application  from Solaris i86
    to Solaris sparc.

    I want to know are there any guidelines and a list of issues
    (like endianness , packing etc.)  for this kind of stuff.
    Any help is appreciated.
thanks
--
Srikant
Please remove  .SPAM from email id to reply ...

 
 
 

porting from solaris i86 to solaris sparc

Post by Ben Ellisto » Tue, 15 Sep 1998 04:00:00


Keep in mind that versions of Solaris prior to 2.5 did not have
pthreads.  So if you've written your Solaris x86 application based on
pthreads, you will need to use a relatively modern version of SPARC
Solaris also.

Ben

 
 
 

porting from solaris i86 to solaris sparc

Post by Casper H.S. Dik - Network Security Engine » Tue, 15 Sep 1998 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


Quote:>Hi all,
>    we are  planning to port a HUGE multithreaded application  from Solaris i86
>    to Solaris sparc.
>    I want to know are there any guidelines and a list of issues
>    (like endianness , packing etc.)  for this kind of stuff.
>    Any help is appreciated.

Well, endianness and alignment is mostly a non-issue, except for file
formats and funny pointers casts.

It might be no more than a recompile.  Since you started on x86, you
should hav egotten network byte order right.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

porting from solaris i86 to solaris sparc

Post by chik » Fri, 18 Sep 1998 04:00:00



> Keep in mind that versions of Solaris prior to 2.5 did not have
> pthreads.  So if you've written your Solaris x86 application based on
> pthreads, you will need to use a relatively modern version of SPARC
> Solaris also.

> Ben

we are targetting  2.6 and 2.7 for our port ...

Quote:>Hi all,
>    we are  planning to port a HUGE multithreaded application  from Solaris i86
>    to Solaris sparc.
>    I want to know are there any guidelines and a list of issues
>    (like endianness , packing etc.)  for this kind of stuff.
>    Any help is appreciated.

|Well, endianness and alignment is mostly a non-issue, except for file
|formats and funny pointers casts.
|
yes there are plenty of them ......

|It might be no more than a recompile.  Since you started on x86, you
|should hav egotten network byte order right.

it is not all that simple .......
e.g there  is  parameter passing problem  .....
e.g sparc is not consitant about passing parameters for routines  thru stack ... it some
times uses registers...... Also  it always pushes all parameters as full words ... (4
bytes)
even shorts take up 4 bytes when it is passed thru stack ...
Also
consider a union

union {
    short  i[2];
    int    j;
 } u ;

now  assign u.j = 0x12345678

on intel u.i[0]  is 0x5678 and
            u.i[1]  is 0x1234

but on sparc it's the other way round ...
It's these kind of behaviours I am looking for ...
--
Srikant

 
 
 

porting from solaris i86 to solaris sparc

Post by Joerg Schilli » Mon, 21 Sep 1998 04:00:00





>we are targetting  2.6 and 2.7 for our port ...

>>    I want to know are there any guidelines and a list of issues
>>    (like endianness , packing etc.)  for this kind of stuff.
>>    Any help is appreciated.

>|Well, endianness and alignment is mostly a non-issue, except for file
>|formats and funny pointers casts.
>|
>yes there are plenty of them ......

This could have been avoided if the first design was made right ;-)

Quote:>|It might be no more than a recompile.  Since you started on x86, you
>|should hav egotten network byte order right.

>it is not all that simple .......
>e.g there  is  parameter passing problem  .....
>e.g sparc is not consitant about passing parameters for routines  thru stack ... it some
>times uses registers...... Also  it always pushes all parameters as full words ... (4
>bytes)
>even shorts take up 4 bytes when it is passed thru stack ...

If you depend on this, your program is not ANSI C-compliant.

Function call parameter format is handled by the C-compiler if the number of
parameters is known. If a function uses a variable number of arguments, the use
of stdarg.h hides parameter passing oddities from the program.

Of course, if you would have asked for problems while porting to the PowerPC...
Motorola made an odd design for the official vararg PPC ABI.
Sun already needed to add a new macro "va_copy()" to the standard to allow
the implementing of the '$' format in printf(). I needed to add another
macro "va_arg_list()" that allows to retrieve a 'va_list' type
argument from the variable arg list.

Quote:>Also
>consider a union

>union {
>    short  i[2];
>    int    j;
> } u ;

>now  assign u.j = 0x12345678

>on intel u.i[0]  is 0x5678 and
>            u.i[1]  is 0x1234

If your program relies on such oddities, it is buggy.

Joerg

--



URL:  http://www.fokus.gmd.de/usr/schilling    ftp://ftp.fokus.gmd.de/pub/unix

 
 
 

porting from solaris i86 to solaris sparc

Post by Casper H.S. Dik - Network Security Engine » Tue, 22 Sep 1998 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


Quote:>|Well, endianness and alignment is mostly a non-issue, except for file
>|formats and funny pointers casts.
>yes there are plenty of them ......

Funny casts are casts when pointers in the middle of structures are
cast from char * to pointers requiring more alignment.

E.g.:

        char foo[16];

        int *p = (int *) &foo[3];

Casts using values returned by malloc are no problem.

Quote:>|It might be no more than a recompile.  Since you started on x86, you
>|should hav egotten network byte order right.
>it is not all that simple .......
>e.g there  is  parameter passing problem  .....
>e.g sparc is not consitant about passing parameters for routines  thru stack ... it some
>times uses registers...... Also  it always pushes all parameters as full words ... (4
>bytes)
>even shorts take up 4 bytes when it is passed thru stack ...

So?  If you care about that in your high level language programs, you're
in the wrong business.

If you program a high level language, it really doesn't matter at
all how parameters are passed.

Quote:>Also
>consider a union
>union {
>    short  i[2];
>    int    j;
> } u ;
>now  assign u.j = 0x12345678
>on intel u.i[0]  is 0x5678 and
>            u.i[1]  is 0x1234
>but on sparc it's the other way round ...
>It's these kind of behaviours I am looking for ...

That's an endianess problem.

Again, most code doesn't suffer from this.  Even when people use
unions, they're mostly *not* used to convert between types.

Note that assigning to u.j and than looking at i[0 .. 1] invokes
undefined behavious and is not legal in ANSI C.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

porting from solaris i86 to solaris sparc

Post by chik » Fri, 25 Sep 1998 04:00:00


Hi  netters,
    Let me give some history of the application we have ......
    year back it was written in PASCAL for some flavor of UNIX on intel 86

    Then it was converted to C using PASCAL to C convertor.
    Later on it was made multithreaded and was cleaned up partially.

    Later it was ported to Intel 86 Solaris 2.6 and used posix threads.
    ( don't laugh please :(   )
    The application needs to be in User as well as Kernel mode (don't ask me
    how it was done in PASCAL but in C on  Solaris 2.6  we have a written
    pseudo  driver to which we make ioctl calls to enter in kernel mode)

    Now after this kind of processing  the code is obviously not clean.
    It is  NOT ANSI compliant.

    We plan to make it ansi compliant.  Some of the issues we have identified
    are

    1> endianness
    2> parameter passing.
        e.g.  consider
        struct sample {
            int     a;
            short b;
            int     c;
    };

    void func1(int x, short y, int z);
    void func2(struct sample *abc);

    main()
    {
        int p=1;
        short q = 2;
        int r = 3;

        func1(p,q,r);
    }

    func1(int x, short y, int z)
    {
        /* some processing */
        func2(&x);
     }

    func2(struct sample *abc)
    {
        some code
    }

Now this  code is what we have ...... I know that this is not going to work
on SPARC and Solaris 2.7  so we NEED TO CORRECT THIS stuff.

I am not cribbing  about this feature not being there ... We have merely made
note to change all such occurrences.

    3>There are also funny pointer casts
    4> There are casts like
        int i;
        long *j ;
        j = (long *) i ;   /* alignment issue  in 2.7*/
    5> File storage
    6> inline assembly
    7> Packed structures
    8> Punning unions

    These are only some of the issues  we have identified.
    I am sure there might be lot more issues.

    Now what I am looking for is guidance in terms of the nature of issues
    we might have overlooked. ( and not the criticism about the bad coding
    standards.. :( . this is an age old code and there is no point in criticizing the
people
    we don't know ).       Also any  thing which can help us achieve the goal.

    we are constantly studying the code ....  SPARC, intel, and other  manuals.
    and every time we go through the code    we come across some new issues
    ( I will be compiling a kind of  report   and will post it here if we are successful).

    Now I want help from who ever can help us to hunt for such issues ...
    The code is really HUGE  (about a million lines)

    In short .. we want to know what all properties a 'bad'  but working program can have
   So  every bit of help is appreciated.
Thanks
Srikant

Note for CASPER and other netters:
    I find your comments very helpful  but the problem is the propagation time between
    your news server to my news server is very high and it takes around  6 days for your
    posts to reach my server. Also replies from  some news servers never reach here.

    So I do a cut'n'paste from my dejanews usenet search  and repost the
    clarifications.....   hence the references in   the headers may not be accurate.
Thanks
Srikant

Quote:>        char foo[16];

>        int *p = (int *) &foo[3];

>Casts using values returned by malloc are no problem.

>>|It might be no more than a recompile.  Since you started on x86, you
>>|should hav egotten network byte order right.

>>it is not all that simple .......
>>e.g there  is  parameter passing problem  .....
>>e.g sparc is not consitant about passing parameters for routines  thru stack ... it some
>>times uses registers...... Also  it always pushes all parameters as full words ... (4
>>bytes)
>>even shorts take up 4 bytes when it is passed thru stack ...

>So?  If you care about that in your high level language programs, you're
>in the wrong business.

>If you program a high level language, it really doesn't matter at
>all how parameters are passed.

>>Also
>>consider a union

>>union {
>>    short  i[2];
>>    int    j;
>> } u ;

>>now  assign u.j = 0x12345678

>>on intel u.i[0]  is 0x5678 and
>>            u.i[1]  is 0x1234

>>but on sparc it's the other way round ...
>>It's these kind of behaviours I am looking for ...

>That's an endianess problem.

>Again, most code doesn't suffer from this.  Even when people use
>unions, they're mostly *not* used to convert between types.

>Note that assigning to u.j and than looking at i[0 .. 1] invokes
>undefined behavious and is not legal in ANSI C.

>Casper