Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.programmer.misc > #1516 > unrolled thread

CPU Type field in LX header

Back to article view | Back to comp.os.os2.programmer.misc

Contents

  CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-22 18:49 +0200
    Re: CPU Type field in LX header "Doug Bissett" <dougb007!SPAM@telus.net> - 2016-10-22 17:32 +0000
      Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-23 18:35 +0200
        Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-24 11:20 +0200
        Re: CPU Type field in LX header "Doug Bissett" <dougb007!SPAM@telus.net> - 2016-10-25 16:50 +0000
          Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-26 17:37 +0200
            Re: CPU Type field in LX header "Doug Bissett" <dougb007!SPAM@telus.net> - 2016-10-26 19:15 +0000
              Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-29 15:41 +0200
                Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-29 11:43 -0700
                  Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-11-09 19:36 -0600
                    Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-11-10 08:52 -0800
                      Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-11-11 10:41 -0600
                        Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-11-11 17:04 -0800
                Re: CPU Type field in LX header "Doug Bissett" <dougb007!SPAM@telus.net> - 2016-10-29 22:22 +0000
                  Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-11-01 17:47 +0100
                    Re: CPU Type field in LX header "Doug Bissett" <dougb007!SPAM@telus.net> - 2016-11-01 19:18 +0000
    Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-22 10:48 -0700
      Re: CPU Type field in LX header Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-10-22 21:58 +0200
        Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-22 23:47 +0200
          Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-22 20:05 -0700
            Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-23 11:08 +0200
              Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-23 10:33 -0700
                Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-24 12:36 +0200
                  Re: CPU Type field in LX header Peter Flass <peter_flass@yahoo.com> - 2016-10-25 16:53 -0400
                    Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-27 10:49 +0200
                      Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-28 21:14 -0700
                        Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-31 14:14 +0100
                          Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-31 07:59 -0700
                            Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-11-01 14:46 +0100
                    Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-28 21:07 -0700
        Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-22 20:00 -0700
          Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-23 10:46 +0200
            Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-23 10:58 -0700
              Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-24 13:04 +0200
                Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-28 21:28 -0700
                  Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-31 14:49 +0100
              Re: CPU Type field in LX header "A.D. Fundum" <what.ever@neverm.ind> - 2016-10-24 13:24 +0200
      Re: CPU Type field in LX header Paul Smedley <paul@smedley.id.au> - 2016-10-23 11:49 +1030
        Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-22 20:11 -0700
          Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-23 11:09 -0700
            Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-10-26 15:44 -0500
              Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-28 20:56 -0700
                Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-11-09 19:38 -0600
          Re: CPU Type field in LX header Paul Smedley <paul@smedley.id.au> - 2016-10-27 19:30 +1030
            Re: CPU Type field in LX header Paul Smedley <paul@smedley.id.au> - 2016-10-29 11:39 +1030
              Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-28 20:54 -0700
      Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-23 18:45 +0200
        Re: CPU Type field in LX header Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-10-23 19:32 +0200
        Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-23 11:06 -0700
      Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-10-26 13:44 -0500
        Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-29 14:37 +0200
          Re: CPU Type field in LX header Paul Smedley <paul@smedley.id.au> - 2016-10-30 12:13 +1030
            Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-30 08:57 +0100
          Re: CPU Type field in LX header "Steven Levine" <steve53@nomail.earthlink.net> - 2016-11-09 19:54 -0600
            Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-11-12 14:48 +0100
    Re: CPU Type field in LX header Dave Yeo <dave.r.yeo@gmail.com> - 2016-10-22 11:02 -0700
    Re: CPU Type field in LX header Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-10-22 21:54 +0200
    Re: CPU Type field in LX header Lars Erdmann <lars.erdmann@arcor.de> - 2016-10-23 12:56 +0200
      Re: CPU Type field in LX header David Parsons <dwparsons@t-online.de> - 2016-10-23 18:20 +0200
        Re: CPU Type field in LX header Peter Flass <peter_flass@yahoo.com> - 2016-10-23 15:11 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#1548

On Sun, 23 Oct 2016 18:09:43 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> There's also the question of whether OS/2 actually supports SSE.
> A testcase that was suggested to me was running the Flac testsuite in 
> twice as many sessions as the number of enabled cores. While one session 
> passed the testcase, multiple sessions failed until only one was left 
> which passed.
> This implies that the OS/2 kernel does not save the XMMS registers 
> during a context switch and SSE (and MMX?) code will fail if more then 
> one thread accesses the XMMS registers

If I understand the Intel docs, it should.  If the hardware indicates 
that support exists, current kernels will use fxsave/fxrstr and will 
set cr4.OSFXSR which means the XMM and MXCSR registers will be saved 
and restored by fxsave/fxrstr.  Of course, this does not mean that the
code is defect free.

BTW, what do you mean by XMMS registers?  This is a term used by the 
Intel docs.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1553

Steven Levine wrote:
> On Sun, 23 Oct 2016 18:09:43 UTC, Dave Yeo <dave.r.yeo@gmail.com>
> wrote:
>
> Hi Dave,
>
>> There's also the question of whether OS/2 actually supports SSE.
>> A testcase that was suggested to me was running the Flac testsuite in
>> twice as many sessions as the number of enabled cores. While one session
>> passed the testcase, multiple sessions failed until only one was left
>> which passed.
>> This implies that the OS/2 kernel does not save the XMMS registers
>> during a context switch and SSE (and MMX?) code will fail if more then
>> one thread accesses the XMMS registers
>
> If I understand the Intel docs, it should.  If the hardware indicates
> that support exists, current kernels will use fxsave/fxrstr and will
> set cr4.OSFXSR which means the XMM and MXCSR registers will be saved
> and restored by fxsave/fxrstr.  Of course, this does not mean that the
> code is defect free.

That's what I thought (assuming you mean when doing a context switch), 
but the FLAC failure implies otherwise, at least in an SMP environment.

>
> BTW, what do you mean by XMMS registers?  This is a term used by the
> Intel docs.

Typo, meant XMM
Dave

[toc] | [prev] | [next] | [standalone]

#1570

On Sat, 29 Oct 2016 03:56:40 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> > and restored by fxsave/fxrstr.  Of course, this does not mean that the
> > code is defect free.
> 
> That's what I thought (assuming you mean when doing a context switch), 
> but the FLAC failure implies otherwise, at least in an SMP environment.

True.  It would take some debugging to identify what the cause of the 
failure really is.

Steve 


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1550

Hi Dave,

On 23/10/16 13:41, Dave Yeo wrote:
> Paul Smedley wrote:
>> Hi Dave,
>>
>> On 23/10/16 04:18, Dave Yeo wrote:
>>> Our GCC does have a bug with SSE+ instructions, it doesn't align them
>>> properly unless forced with -mstackrealign (there's also
>>> -mpreferred-stack-boundary=4)
>> This might be fixed in GCC 6.x - do you have a simple testcase?
>>
>
> You should be able to just do some floating point math and compile with
> -msse2 -mfpmath=sse and see if it crashes with the xmms registers not
> aligned. Might want to target a newer architecture as well.
> Dave
>
OK, will try come up with a testcase, then re-test with GCC 6.2

Cheers,

Paul

[toc] | [prev] | [next] | [standalone]

#1551

Hi Dave,

On 27/10/16 19:30, Paul Smedley wrote:
> Hi Dave,
>
> On 23/10/16 13:41, Dave Yeo wrote:
>> Paul Smedley wrote:
>>> Hi Dave,
>>>
>>> On 23/10/16 04:18, Dave Yeo wrote:
>>>> Our GCC does have a bug with SSE+ instructions, it doesn't align them
>>>> properly unless forced with -mstackrealign (there's also
>>>> -mpreferred-stack-boundary=4)
>>> This might be fixed in GCC 6.x - do you have a simple testcase?
>>>
>>
>> You should be able to just do some floating point math and compile with
>> -msse2 -mfpmath=sse and see if it crashes with the xmms registers not
>> aligned. Might want to target a newer architecture as well.
>> Dave
>>
> OK, will try come up with a testcase, then re-test with GCC 6.2

http://smedley.id.au/tmp/sse2.cpp runs fine with -msse2 when built with 
g++ from 4.4.6, 4.9.2 and 6.2.0

Only 6.2.0 has the stack align changes :/

I might try compiling qtgui4.dll with gcc 6.2.0 without the changes from 
https://trac.netlabs.org/qt4/ticket/187 - that at least is a known 
failure case...

Cheers,

Paul

[toc] | [prev] | [next] | [standalone]

#1552

Paul Smedley wrote:
> Hi Dave,
>
> On 27/10/16 19:30, Paul Smedley wrote:
>> Hi Dave,
>>
>> On 23/10/16 13:41, Dave Yeo wrote:
>>> Paul Smedley wrote:
>>>> Hi Dave,
>>>>
>>>> On 23/10/16 04:18, Dave Yeo wrote:
>>>>> Our GCC does have a bug with SSE+ instructions, it doesn't align them
>>>>> properly unless forced with -mstackrealign (there's also
>>>>> -mpreferred-stack-boundary=4)
>>>> This might be fixed in GCC 6.x - do you have a simple testcase?
>>>>
>>>
>>> You should be able to just do some floating point math and compile with
>>> -msse2 -mfpmath=sse and see if it crashes with the xmms registers not
>>> aligned. Might want to target a newer architecture as well.
>>> Dave
>>>
>> OK, will try come up with a testcase, then re-test with GCC 6.2
>
> http://smedley.id.au/tmp/sse2.cpp runs fine with -msse2 when built with
> g++ from 4.4.6, 4.9.2 and 6.2.0
>
> Only 6.2.0 has the stack align changes :/
>
> I might try compiling qtgui4.dll with gcc 6.2.0 without the changes from
> https://trac.netlabs.org/qt4/ticket/187 - that at least is a known
> failure case...
>

I'd guess the stack has to become mis-aligned first for the bug to show 
up. The known failure I know of is Mozilla.
IIRC, a Mingw guy introduced the same fix (-mstackrealign) into FLAC and 
I requested adding __OS2__ to the fix, though I never saw the failure 
while running the test suite. So it implies that Mingw has the same problem
Dave

[toc] | [prev] | [next] | [standalone]

#1532

On 22-10-16 19:48, Dave Yeo wrote:
>
> Our GCC's understand -march (at least as current when released) and -mtune fine
> and for almost all CPU's i686 is a much better choice as it includes a few
> needed instructions for things like atomic operations and perhaps more
> importantly aligns the instructions such that modern CPU's perform much better.
> You can test by targeting a newer CPU then you're using (might need floating
> point code) and getting a sigill (illegal instruction).
> A while back I built a SM targeted at my desktop C2D and it wouldn't run on P4's
> and built a TB targeted at my laptop's Pentium M which ran most everywhere.
> Targeting a CPU with SSE2+ instructions really helps floating point math as it
> is done with the SSE+ instructions and registers instead of the i387+ co-processor.
> Our GCC does have a bug with SSE+ instructions, it doesn't align them properly
> unless forced with -mstackrealign (there's also -mpreferred-stack-boundary=4)
>
> It's the linkers job to set fields in the LX header, all GCC does is produce the
> correct assembly code and obj files and ask the linker to link them into an
> executable (or DLL).
> Wlink could be patched (perhaps already is?) to use i686 in the CPU field but I
> don't know if the kernel would be happy to load something besides i386. I guess
> it would be easy enough to use a hex editor to test and if it works, to file a
> feature request bug.
> Ideally our uname should be updated to report -i686 as well so the toolchain
> automatically targets it
> Dave

Agreed, but it has to be told somehow. I had hoped the compiler would pass the 
information on to the linker but if it does, it seems the linker ignores it.

Out of curiosity I patched the CPU Type field of my test program to i486, i586, 
i686 and i786 and they all compiled and ran successfully even the non-existent i786.

Dave P.

[toc] | [prev] | [next] | [standalone]

#1533

On 23.10.16 18.45, David Parsons wrote:
> Out of curiosity I patched the CPU Type field of my test program to
> i486, i586, i686 and i786 and they all compiled and ran successfully
> even the non-existent i786.

So OS/2 probably ignores the field.


Marcel

[toc] | [prev] | [next] | [standalone]

#1536

David Parsons wrote:
> On 22-10-16 19:48, Dave Yeo wrote:
>>
>> Our GCC's understand -march (at least as current when released) and
>> -mtune fine
>> and for almost all CPU's i686 is a much better choice as it includes a
>> few
>> needed instructions for things like atomic operations and perhaps more
>> importantly aligns the instructions such that modern CPU's perform
>> much better.
>> You can test by targeting a newer CPU then you're using (might need
>> floating
>> point code) and getting a sigill (illegal instruction).
>> A while back I built a SM targeted at my desktop C2D and it wouldn't
>> run on P4's
>> and built a TB targeted at my laptop's Pentium M which ran most
>> everywhere.
>> Targeting a CPU with SSE2+ instructions really helps floating point
>> math as it
>> is done with the SSE+ instructions and registers instead of the i387+
>> co-processor.
>> Our GCC does have a bug with SSE+ instructions, it doesn't align them
>> properly
>> unless forced with -mstackrealign (there's also
>> -mpreferred-stack-boundary=4)
>>
>> It's the linkers job to set fields in the LX header, all GCC does is
>> produce the
>> correct assembly code and obj files and ask the linker to link them
>> into an
>> executable (or DLL).
>> Wlink could be patched (perhaps already is?) to use i686 in the CPU
>> field but I
>> don't know if the kernel would be happy to load something besides
>> i386. I guess
>> it would be easy enough to use a hex editor to test and if it works,
>> to file a
>> feature request bug.
>> Ideally our uname should be updated to report -i686 as well so the
>> toolchain
>> automatically targets it
>> Dave
>
> Agreed, but it has to be told somehow. I had hoped the compiler would
> pass the information on to the linker but if it does, it seems the
> linker ignores it.

Using the recommended LDFLAGS=-Zomf, emxomfld would have to understand 
and pass on the information to the linker and the linker would need to 
understand it. Emxomfld and the OpenWatcom linker could probably be 
fixed to make it work if someone is interested in doing the work. Steven 
has commit access to OpenWatcom.

>
> Out of curiosity I patched the CPU Type field of my test program to
> i486, i586, i686 and i786 and they all compiled and ran successfully
> even the non-existent i786.
>

That's interesting.
Dave

[toc] | [prev] | [next] | [standalone]

#1546

On Sat, 22 Oct 2016 17:48:37 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> > There is a field in the LX header which specifies the CPU Type but all
> > files show i386 even though I believe that many are at i686.

As Dave noted this is probably gcc.  The relevant wlink code is

    case CMT_WAT_PROC_MODEL:
    case CMT_MS_PROC_MODEL:
        proc = GET_U8_UN( ObjBuff ) - '0';
        if( proc > FmtData.cpu_type )
            FmtData.cpu_type = proc;
        break;

and

    if( FmtData.cpu_type <= 3 ) {
        exe_head.cpu_type = OSF_CPU_386;
    } else {
        exe_head.cpu_type = OSF_CPU_486;
    }

which says that the CPU type comes from the OMF record and wlink maps 
the CPU type to either 386 or 486.

> > I've complied a test program here with 'gcc -march=i686 test.c' which
> > compiles and runs successfully but it also shows the CPU type as i386.

What linker did you use and did you check the COMMENT records 
generated by gcc?

> > Could it be that the -march switch is silently ignored in our gcc builds?
> > For the record I used gcc v4.5.2.

That's pretty antique.

> It's the linkers job to set fields in the LX header, all GCC does is 
> produce the correct assembly code and obj files and ask the linker to 
> link them into an executable (or DLL).

That's sorta true.  As noted above, gcc is responsible for indicating 
the CPU type required by each object model.

> Wlink could be patched (perhaps already is?) to use i686 in the CPU 
> field but I don't know if the kernel would be happy to load something 
> besides i386.

AFAIK, it would not care.  I've not seen any code that cares about the
CPU type field in the LX header.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1557

On 26-10-16 20:44, Steven Levine wrote:
> On Sat, 22 Oct 2016 17:48:37 UTC, Dave Yeo <dave.r.yeo@gmail.com>
> wrote:
>
> Hi Dave,
>
>>> There is a field in the LX header which specifies the CPU Type but all
>>> files show i386 even though I believe that many are at i686.
>
> As Dave noted this is probably gcc.  The relevant wlink code is
>
>      case CMT_WAT_PROC_MODEL:
>      case CMT_MS_PROC_MODEL:
>          proc = GET_U8_UN( ObjBuff ) - '0';
>          if( proc > FmtData.cpu_type )
>              FmtData.cpu_type = proc;
>          break;
>
> and
>
>      if( FmtData.cpu_type <= 3 ) {
>          exe_head.cpu_type = OSF_CPU_386;
>      } else {
>          exe_head.cpu_type = OSF_CPU_486;
>      }
>
> which says that the CPU type comes from the OMF record and wlink maps
> the CPU type to either 386 or 486.
>
>>> I've complied a test program here with 'gcc -march=i686 test.c' which
>>> compiles and runs successfully but it also shows the CPU type as i386.
>
> What linker did you use and did you check the COMMENT records
> generated by gcc?
>
>>> Could it be that the -march switch is silently ignored in our gcc builds?
>>> For the record I used gcc v4.5.2.
>
> That's pretty antique.
>
>> It's the linkers job to set fields in the LX header, all GCC does is
>> produce the correct assembly code and obj files and ask the linker to
>> link them into an executable (or DLL).
>
> That's sorta true.  As noted above, gcc is responsible for indicating
> the CPU type required by each object model.
>
>> Wlink could be patched (perhaps already is?) to use i686 in the CPU
>> field but I don't know if the kernel would be happy to load something
>> besides i386.
>
> AFAIK, it would not care.  I've not seen any code that cares about the
> CPU type field in the LX header.
>
> Steven
>
>
Hi Steven,

Those 2 snippets confirm my assumption, thanks.

As for GCC, the latest I've found on Paul's site is 4.9.2, not so much newer and 
anyway I don't use C very often & when I do I normally use Watcom.

As for the linker, it is an old version of wl.exe which seems to be a patched 
version of wlink v1.6.
I don't have the source for it and I don't know now where I got it from so I 
don't know what is patched. When you invoke it, it says something about 
experimental HLL.
I noticed that ANPM offers a version of wl, I'll give that a try and see if it 
is any better.

Dave P.

[toc] | [prev] | [next] | [standalone]

#1561

Hi Dave,

On 29/10/16 23:07, David Parsons wrote:
> As for GCC, the latest I've found on Paul's site is 4.9.2, not so much
> newer and anyway I don't use C very often & when I do I normally use
> Watcom.

6.2.0 is available - I posted a link at os2world. It's probably tested 
well enough that I should add it to my site as well now....

Cheers,

Paul

[toc] | [prev] | [next] | [standalone]

#1562

On 30-10-16 02:43, Paul Smedley wrote:
> Hi Dave,
>
> On 29/10/16 23:07, David Parsons wrote:
>> As for GCC, the latest I've found on Paul's site is 4.9.2, not so much
>> newer and anyway I don't use C very often & when I do I normally use
>> Watcom.
>
> 6.2.0 is available - I posted a link at os2world. It's probably tested well
> enough that I should add it to my site as well now....

Thanks Paul, I'll give it a try.

Dave P.

[toc] | [prev] | [next] | [standalone]

#1571

On Sat, 29 Oct 2016 12:37:38 UTC, David Parsons 
<dwparsons@t-online.de> wrote:

Hi David,

> As for the linker, it is an old version of wl.exe which seems to be a patched 
> version of wlink v1.6.

That would be Knut's original version of wlink with HLL debug support.
 It's probably fine for anyone not building Firefox.  The memory 
management in Knut's patch was not quite up to building something as 
big as Firefox with debug info.

You can find copies of recent builds of some OpenWatcom components at:

  http://www.warpcave.com/OpenWatcom

Now that openwatcom.org is back online, there will probably be a 
OpenWatcom release for OS/2 release in the relatively near future.  
Gregg and I are trying to decide what to include in the release, what 
to name the release and where to distribute it.

> I don't have the source for it and I don't know now where I got it from so I 
> don't know what is patched.

There never was a repository for this.  Knut distributed the diffs and
these formed the basis of my modifications to the then current 
sources.  My modifications have been committed to the OpenWatcom 
Perforce repository.

> When you invoke it, it says something about 
> experimental HLL.

You mean like:

[d:\tmp]wlink
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited 
Availability
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Press CTRL/Z and then RETURN to finish

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1575

On 10-11-16 02:54, Steven Levine wrote:
> On Sat, 29 Oct 2016 12:37:38 UTC, David Parsons
> <dwparsons@t-online.de> wrote:
>
>> When you invoke it, it says something about
>> experimental HLL.
>
> You mean like:
>
> [d:\tmp]wlink
> ** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited
> Availability
> Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> Press CTRL/Z and then RETURN to finish
>
> Steven
>

Yes, except the one I have claims to be Version 1.6beta1.

I noticed that there is a version 2.0beta1 release 6 available via ANPM.

Thanks for the info & help.

Dave P.

[toc] | [prev] | [next] | [standalone]

#1519

David Parsons wrote:
> Hello all,
>
> I upgraded a few DLLs used by Firefox & co to i686 standard recently and
> noticed a significant performance improvement so I'm now want to update
> the rest to i686 also. I've been able to do some with the help of ANPM
> (it would be easier if ANPM showed individual file dates & size) but I
> can not find a way to tell what standard a particular file is at.
>
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.
> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.

Our GCC's understand -march (at least as current when released) and 
-mtune fine and for almost all CPU's i686 is a much better choice as it 
includes a few needed instructions for things like atomic operations and 
perhaps more importantly aligns the instructions such that modern CPU's 
perform much better.
You can test by targeting a newer CPU then you're using (might need 
floating point code) and getting a sigill (illegal instruction).
A while back I built a SM targeted at my desktop C2D and it wouldn't run 
on P4's and built a TB targeted at my laptop's Pentium M which ran most 
everywhere.
Targeting a CPU with SSE2+ instructions really helps floating point math 
as it is done with the SSE+ instructions and registers instead of the 
i387+ co-processor.
Our GCC does have a bug with SSE+ instructions, it doesn't align them 
properly unless forced with -mstackrealign (there's also 
-mpreferred-stack-boundary=4)

>
> I've searched on the internet and read though many pages of switches
> available for gcc but not found anything other than march & mtune.
>
> Does anyone know if there are any other switches I should use or have
> any advice?
>

It's the linkers job to set fields in the LX header, all GCC does is 
produce the correct assembly code and obj files and ask the linker to 
link them into an executable (or DLL).
Wlink could be patched (perhaps already is?) to use i686 in the CPU 
field but I don't know if the kernel would be happy to load something 
besides i386. I guess it would be easy enough to use a hex editor to 
test and if it works, to file a feature request bug.
Ideally our uname should be updated to report -i686 as well so the 
toolchain automatically targets it
Dave

[toc] | [prev] | [next] | [standalone]

#1520

On 22.10.16 18.49, David Parsons wrote:
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.

I would not bet that OS/2 will execute anything else.


> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.

AFAIK march is working as expected.


Marcel

[toc] | [prev] | [next] | [standalone]

#1529

I am fairly sure that the linker is supposed to correctly set this field.
But I would not be surprised if any linker ever written for OS/2 just 
ignores to properly set this field.

Additionally the LX spec only defines these values for CPU type:

     01H - 80286 or upwardly compatible CPU is required to execute this 
module.
     02H - 80386 or upwardly compatible CPU is required to execute this 
module.
     03H - 80486 or upwardly compatible CPU is required to execute this 
module.

That said, a 16-bit OS/2 linker will likely set this field to 01h 
whereas a 32-bit OS/2 linker will set it to 02h just to indicate that a
32-bit CPU is needed as a 16-bit CPU is not enough for OS/2 >= version 2.0.

Anything higher than a 486 is therefore undefined in the standard.
I don't think you can rely on anything set in this field.


Lars


Am 22.10.16 um 18.49 schrieb David Parsons:
> Hello all,
>
> I upgraded a few DLLs used by Firefox & co to i686 standard recently and
> noticed a significant performance improvement so I'm now want to update
> the rest to i686 also. I've been able to do some with the help of ANPM
> (it would be easier if ANPM showed individual file dates & size) but I
> can not find a way to tell what standard a particular file is at.
>
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.
> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.
>
> I've searched on the internet and read though many pages of switches
> available for gcc but not found anything other than march & mtune.
>
> Does anyone know if there are any other switches I should use or have
> any advice?
>
> Regards,
> Dave P.

[toc] | [prev] | [next] | [standalone]

#1530

I have version 10 of that spec from 1996 and that is what it seems like to me.
I have read lots of switches for the various linkers we have and found nothing 
to imply that any of them use the -march setting.

It looks as though I am out of luck unless anyone knows of another way to tell 
how an exe or dll was compiled.

Dave P.

On 23-10-16 12:56, Lars Erdmann wrote:
> I am fairly sure that the linker is supposed to correctly set this field.
> But I would not be surprised if any linker ever written for OS/2 just ignores to
> properly set this field.
>
> Additionally the LX spec only defines these values for CPU type:
>
>      01H - 80286 or upwardly compatible CPU is required to execute this module.
>      02H - 80386 or upwardly compatible CPU is required to execute this module.
>      03H - 80486 or upwardly compatible CPU is required to execute this module.
>
> That said, a 16-bit OS/2 linker will likely set this field to 01h whereas a
> 32-bit OS/2 linker will set it to 02h just to indicate that a
> 32-bit CPU is needed as a 16-bit CPU is not enough for OS/2 >= version 2.0.
>
> Anything higher than a 486 is therefore undefined in the standard.
> I don't think you can rely on anything set in this field.
>
>
> Lars
>

[toc] | [prev] | [next] | [standalone]

#1538

David Parsons <dwparsons@t-online.de> wrote:
> I have version 10 of that spec from 1996 and that is what it seems like to me.
> I have read lots of switches for the various linkers we have and found nothing 
> to imply that any of them use the -march setting.
> 
> It looks as though I am out of luck unless anyone knows of another way to tell 
> how an exe or dll was compiled.
> 
> Dave P.
> 
> On 23-10-16 12:56, Lars Erdmann wrote:
>> I am fairly sure that the linker is supposed to correctly set this field.
>> But I would not be surprised if any linker ever written for OS/2 just ignores to
>> properly set this field.
>> 
>> Additionally the LX spec only defines these values for CPU type:
>> 
>> 01H - 80286 or upwardly compatible CPU is required to execute this module.
>> 02H - 80386 or upwardly compatible CPU is required to execute this module.
>> 03H - 80486 or upwardly compatible CPU is required to execute this module.
>> 
>> That said, a 16-bit OS/2 linker will likely set this field to 01h whereas a
>> 32-bit OS/2 linker will set it to 02h just to indicate that a
>> 32-bit CPU is needed as a 16-bit CPU is not enough for OS/2 >= version 2.0.
>> 
>> Anything higher than a 486 is therefore undefined in the standard.
>> I don't think you can rely on anything set in this field.
>> 

The OMF spec includes optional comments that often will include the
compiler and options used for the compile.  I don't know enough about LX
format to say whether any of that carries over.

-- 
Pete

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.os.os2.programmer.misc

csiph-web