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 1 of 3  [1] 2 3  Next page →

#1516 — CPU Type field in LX header

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] | [next] | [standalone]

#1517

On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons 
<dwparsons@t-online.de> 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.

Using the YUM command line should tell you what you have installed.

Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
when you install things. 

 ANPM has an outstanding request to add a feature to be able to change
between versions, but it has not been done yet. Note that file date & 
size means nothing, and individual files seem to have no information 
about what version they are (no BLDLEVEL information). Some of them, 
apparently, have a way to query their version, but it seems that it is
inconsistent, and you need to know exactly how to do it for different 
files.

> 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?

Wait for the ANPM update, I guess, although YUM has an add on that 
will do it when you use the command line (which is how ANPM will do 
it). Sorry, I don't remember what it is called.

> Regards,
> Dave P.


-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

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

#1531

On 22-10-16 19:32, Doug Bissett wrote:
> On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons
> <dwparsons@t-online.de> 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.
>
> Using the YUM command line should tell you what you have installed.
>
> Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
> when you install things.
>
>   ANPM has an outstanding request to add a feature to be able to change
> between versions, but it has not been done yet. Note that file date &
> size means nothing, and individual files seem to have no information
> about what version they are (no BLDLEVEL information). Some of them,
> apparently, have a way to query their version, but it seems that it is
> inconsistent, and you need to know exactly how to do it for different
> files.
>

Yes, bldlevel would be best if it was guaranteed to be updated whenever anything 
changed, including the build flags, but that would mean a lot of extra work for BWW.
I appreciate that using the date & size information is not foolproof but it 
would be correct in most cases and requires little extra work.

What does the /DUP switch do, is there a list of switches available anywhere?

Dave P.

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

#1539

 > that would mean a lot of extra work for BWW.

If BWW is involved, they may as well rename their main product Firefox
for OS/2 to Firefox for/fuer eComStation 2.0+. This always implies the
use of a i686+ CPU.


-- 

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

#1543

On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons 
<dwparsons@t-online.de> wrote:

> On 22-10-16 19:32, Doug Bissett wrote:
> > On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons
> > <dwparsons@t-online.de> 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.
> >
> > Using the YUM command line should tell you what you have installed.
> >
> > Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
> > when you install things.
> >
> >   ANPM has an outstanding request to add a feature to be able to change
> > between versions, but it has not been done yet. Note that file date &
> > size means nothing, and individual files seem to have no information
> > about what version they are (no BLDLEVEL information). Some of them,
> > apparently, have a way to query their version, but it seems that it is
> > inconsistent, and you need to know exactly how to do it for different
> > files.
> >
> 
> Yes, bldlevel would be best if it was guaranteed to be updated whenever anything 
> changed, including the build flags, but that would mean a lot of extra work for BWW.
> I appreciate that using the date & size information is not foolproof but it 
> would be correct in most cases and requires little extra work.

I wouldn't bet on it...

> What does the /DUP switch do, is there a list of switches available anywhere?
> 
> Dave P.

"/DUP" is undocumented, and is really meant for development, but it 
does show the version that is installed.Try it, and it will make 
sense. I don't know of any others.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

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

#1545

On 25-10-16 18:50, Doug Bissett wrote:
> On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons
> <dwparsons@t-online.de> wrote:
>
>> What does the /DUP switch do, is there a list of switches available anywhere?
>>
>> Dave P.
>
> "/DUP" is undocumented, and is really meant for development, but it
> does show the version that is installed.Try it, and it will make
> sense. I don't know of any others.
>

Ok, It helps a bit but I presume the platform column shows which packages it has 
available or has installed itself and not the file version on disk which was 
installed from a zip file before ANPM became available.

Still I think it will be helpful, thanks.

Dave P.

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

#1547

On Wed, 26 Oct 2016 15:37:35 UTC, David Parsons 
<dwparsons@t-online.de> wrote:

> On 25-10-16 18:50, Doug Bissett wrote:
> > On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons
> > <dwparsons@t-online.de> wrote:
> >
> >> What does the /DUP switch do, is there a list of switches available anywhere?
> >>
> >> Dave P.
> >
> > "/DUP" is undocumented, and is really meant for development, but it
> > does show the version that is installed.Try it, and it will make
> > sense. I don't know of any others.
> >
> 
> Ok, It helps a bit but I presume the platform column shows which packages it has 
> available or has installed itself and not the file version on disk which was 
> installed from a zip file before ANPM became available.
> 
> Still I think it will be helpful, thanks.
> 
> Dave P.

You should never get to the files on the disk, from before you 
installed RPM/YUM (PATH and LIBPATH need to have the YUM paths first, 
although some insist that the dot entry needs to be first in LIBPATH),
however, it is still possible to use the wrong file, so you really 
should eliminate ALL duplicates of files that are in the \usr 
directory structure, everywhere else on your system (with logical 
exceptions). Once you get that mess cleaned up, ANPM (actually YUM) 
will control the versions for you, and all you need to do is keep them
up to date (although that has also been known to cause problems when 
the packages are not built properly).

HTH...
-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

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

#1558

On 26-10-16 21:15, Doug Bissett wrote:
> On Wed, 26 Oct 2016 15:37:35 UTC, David Parsons <dwparsons@t-online.de>
> wrote:
>
>> On 25-10-16 18:50, Doug Bissett wrote:
>>> On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons <dwparsons@t-online.de>
>>> wrote:
>>>
>>>> What does the /DUP switch do, is there a list of switches available
>>>> anywhere?
>>>>
>>>> Dave P.
>>>
>>> "/DUP" is undocumented, and is really meant for development, but it does
>>>  show the version that is installed.Try it, and it will make sense. I
>>> don't know of any others.
>>>
>>
>> Ok, It helps a bit but I presume the platform column shows which packages
>> it has available or has installed itself and not the file version on disk
>> which was installed from a zip file before ANPM became available.
>>
>> Still I think it will be helpful, thanks.
>>
>> Dave P.
>
> You should never get to the files on the disk, from before you installed
> RPM/YUM (PATH and LIBPATH need to have the YUM paths first, although some
> insist that the dot entry needs to be first in LIBPATH), however, it is still
> possible to use the wrong file, so you really should eliminate ALL duplicates
> of files that are in the \usr directory structure, everywhere else on your
> system (with logical exceptions). Once you get that mess cleaned up, ANPM
> (actually YUM) will control the versions for you, and all you need to do is
> keep them up to date (although that has also been known to cause problems
> when the packages are not built properly).
>


When I finally got fed up trying to keep adding extra dependencies for Firefox & 
Thunderbird by extracting the files from the zip & rpm files on Netlabs and 
decided to use ANPM, I already had a very mature /usr tree for other programs 
which I wanted to keep & I did not want yet another linux directory structure.

I eliminated any duplicates & moved a few stray linux orientated files into 
/usr/... before running ANPM for the first time.

ANPM added the directories at the beginning of PATH & LIBPATH leaving the 
existing entries where they were duplicating the directories in PATH & LIBPATH 
which I later removed.

I had expected ANPM would overwrite any files already on the disk with its 
version but it seems that it did not overwrite all unfortunately.

So now to the present problem. The Firefox 38.*.* series are appallingly slow at 
scrolling and after updating a few files for another reason I noticed that the 
scrolling was noticeably better with these updates which were i686 files so I 
wanted to see if there were any other i386 files which I could update & perhaps 
gain a bit better performance.

This led to the problem of how to identify i386 versions on the disk.
This should have been easy, just look at the CPU_Type field in the LX header.
As we now know, that field is not set as expected by wl.exe without Steven's patch.
I don't know which linker was used to produce the netlabs files but presumably 
it doesn't set it either.



HTH...

Dave P.

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

#1559

David Parsons wrote:
> I don't know which linker was used to produce the netlabs files but
> presumably it doesn't set it either.

Generally wl.exe (wlink with support for our debugging support).
You could open an issue at the Netlabs RPM site to add Steven's patch
Dave

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

#1569

On Sat, 29 Oct 2016 18:43:47 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

Warpstock kept me away from the newsgroups...

> Generally wl.exe (wlink with support for our debugging support).
> You could open an issue at the Netlabs RPM site to add Steven's patch

What patch?  Do you mean the wlink with HLL debug support?  I've not 
checked, but I would be surprised if it's not already available from 
the Netlabs rpm since it's used to build Firefox.

Steven

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

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

#1572

Steven Levine wrote:
> On Sat, 29 Oct 2016 18:43:47 UTC, Dave Yeo <dave.r.yeo@gmail.com>
> wrote:
>
> Hi Dave,
>
> Warpstock kept me away from the newsgroups...
>
>> Generally wl.exe (wlink with support for our debugging support).
>> You could open an issue at the Netlabs RPM site to add Steven's patch
>
> What patch?  Do you mean the wlink with HLL debug support?  I've not
> checked, but I would be surprised if it's not already available from
> the Netlabs rpm since it's used to build Firefox.
>

Maybe I miss understood. Didn't you say that you'd patched wlink to 
report the CPU architecture? If so, that was the patch I meant. If not, 
sorry for the noise.
Dave

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

#1573

On Thu, 10 Nov 2016 16:52:30 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> Maybe I miss understood. Didn't you say that you'd patched wlink to 
> report the CPU architecture? If so, that was the patch I meant. If not, 
> sorry for the noise.

Perhaps I did not state things clearly.  What I posted was the 
existing code that sets the CPU type field.  This could be modified to
report other CPU types, but I have no plans to do this since it the 
field is effectively ignored by OS/2.

Steven


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

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

#1574

Steven Levine wrote:
> On Thu, 10 Nov 2016 16:52:30 UTC, Dave Yeo <dave.r.yeo@gmail.com>
> wrote:
>
> Hi Dave,
>
>> Maybe I miss understood. Didn't you say that you'd patched wlink to
>> report the CPU architecture? If so, that was the patch I meant. If not,
>> sorry for the noise.
>
> Perhaps I did not state things clearly.  What I posted was the
> existing code that sets the CPU type field.  This could be modified to
> report other CPU types, but I have no plans to do this since it the
> field is effectively ignored by OS/2.
>

OK, thanks for the clarification.
Dave

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

#1560

On Sat, 29 Oct 2016 13:41:33 UTC, David Parsons 
<dwparsons@t-online.de> wrote:

> On 26-10-16 21:15, Doug Bissett wrote:
> > On Wed, 26 Oct 2016 15:37:35 UTC, David Parsons <dwparsons@t-online.de>
> > wrote:
> >
> >> On 25-10-16 18:50, Doug Bissett wrote:
> >>> On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons <dwparsons@t-online.de>
> >>> wrote:
> >>>
> >>>> What does the /DUP switch do, is there a list of switches available
> >>>> anywhere?
> >>>>
> >>>> Dave P.
> >>>
> >>> "/DUP" is undocumented, and is really meant for development, but it does
> >>>  show the version that is installed.Try it, and it will make sense. I
> >>> don't know of any others.
> >>>
> >>
> >> Ok, It helps a bit but I presume the platform column shows which packages
> >> it has available or has installed itself and not the file version on disk
> >> which was installed from a zip file before ANPM became available.
> >>
> >> Still I think it will be helpful, thanks.
> >>
> >> Dave P.
> >
> > You should never get to the files on the disk, from before you installed
> > RPM/YUM (PATH and LIBPATH need to have the YUM paths first, although some
> > insist that the dot entry needs to be first in LIBPATH), however, it is still
> > possible to use the wrong file, so you really should eliminate ALL duplicates
> > of files that are in the \usr directory structure, everywhere else on your
> > system (with logical exceptions). Once you get that mess cleaned up, ANPM
> > (actually YUM) will control the versions for you, and all you need to do is
> > keep them up to date (although that has also been known to cause problems
> > when the packages are not built properly).
> >
> 
> 
> When I finally got fed up trying to keep adding extra dependencies for Firefox & 
> Thunderbird by extracting the files from the zip & rpm files on Netlabs and 
> decided to use ANPM, I already had a very mature /usr tree for other programs 
> which I wanted to keep & I did not want yet another linux directory structure.

That will, for sure, cause problems. 

> I eliminated any duplicates & moved a few stray linux orientated files into 
> /usr/... before running ANPM for the first time.

ANPM uses YUM to determine what is, or is not, installed, not what 
files happen to be in the paths.

> ANPM added the directories at the beginning of PATH & LIBPATH leaving the 
> existing entries where they were duplicating the directories in PATH & LIBPATH 
> which I later removed.

That is simply messy, it won't cause a problem.

> I had expected ANPM would overwrite any files already on the disk with its 
> version but it seems that it did not overwrite all unfortunately.

ANPM simply runs YUM to do the work. YUM expects to know exactly what 
files are in the directory structure. It knows nothing about any stray
files that you may have added (or removed).

> So now to the present problem. The Firefox 38.*.* series are appallingly slow at 
> scrolling and after updating a few files for another reason I noticed that the 
> scrolling was noticeably better with these updates which were i686 files so I 
> wanted to see if there were any other i386 files which I could update & perhaps 
> gain a bit better performance.

I would suggest that you rename your old /usr directory structure, and
install ALL of the packages that ALL of the programs, that you use, 
using ANPM into a new /usr directory structure. Then, eliminate the 
old one. When you do that, ANPM will insist on initializing the 
directory structure with a new downloaded bootstrap file, which is a 
basic RPM/YUM install, with no extras. That will initialize your 
RPM/YUM stuff to what YUM knows about, so you can successfully add 
what you need.

> This led to the problem of how to identify i386 versions on the disk.
> This should have been easy, just look at the CPU_Type field in the LX header.
> As we now know, that field is not set as expected by wl.exe without Steven's patch.
> I don't know which linker was used to produce the netlabs files but presumably 
> it doesn't set it either.

You cannot solve your problems by knowing what is on the disk. You can
only solve them by getting YUM to know what it thinks it installed. 
That means letting YUM do it. ANPM simply runs YUM for you.

> 
> 
> HTH...
> 
> Dave P.


-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

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

#1567

On 30-10-16 00:22, Doug Bissett wrote:
> You cannot solve your problems by knowing what is on the disk. You can
> only solve them by getting YUM to know what it thinks it installed.
> That means letting YUM do it. ANPM simply runs YUM for you.

Of course I can. I only have to identify which files to update and then install 
the packages which contain them using ANPM/YUM. From then on ANPM will manage 
those packages.

Dave P.

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

#1568

On Tue, 1 Nov 2016 16:47:48 UTC, David Parsons <dwparsons@t-online.de>
wrote:

> On 30-10-16 00:22, Doug Bissett wrote:
> > You cannot solve your problems by knowing what is on the disk. You can
> > only solve them by getting YUM to know what it thinks it installed.
> > That means letting YUM do it. ANPM simply runs YUM for you.
> 
> Of course I can. I only have to identify which files to update and then install 
> the packages which contain them using ANPM/YUM. From then on ANPM will manage 
> those packages.
> 
> Dave P.

You will have a LOT of work to do, to even begin to understand what 
might need to be installed by ANPM (RPM/YUM). Don't forget that there 
is a lot more to it than just DLLs.

Just use ANPM to install ALL of the packages that your software needs,
and you will accomplish the same thing, without doing a lot of 
unnecessary work (most packages are pretty small). However, that may 
leave old stuff behind, that will eventually cause problems. Best to 
just move what you have out of the way, and start new with ANPM 
(RPM/YUM). Then you won't be guessing, and the problem will be solved.

The best advice that I can give, about using RPM/YUM when you haven't 
used RPM/YUM before, is to start new, using ANPM. DO NOT even think 
about trying to second guess that stuff, you will only spend untold 
hours digging yourself a hole that will be more difficult to get out 
of. Spending an hour to start over, is much smarter than spending days
trying to figure out what you think you might want to do, and messing 
it up so bad that you will still need to spend that hour fixing the 
problem (time depends on your download speed, I use standard DSL).

You could have done it twice, in the time you spent posting about it.

You must remember that RPM/YUM is a terrible way to do things (even 
the *NIX world has mostly abandoned it), but if you want to use modern
*NIX ports, you need to use it. If you don't use it properly, you can 
tie it in knots, and it won't be pretty.

You have been warned...
-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

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

#1518

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]

#1521

On 22.10.16 19.48, Dave Yeo 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.
>> 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.

Most atomic instructions are available since 486. Only 64 and 128 bit 
atomics are introduced later.

But modern CPUs cannot be classified by a single scalar value anymore. 
Some features also get removed with newer ones. Others depend on the 
manufacturer or product line.


> 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.

Using march has its drawbacks. If you target to a specific CPU type you 
cannot assume that it runs on everything newer.

> 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.

And it sadly fails on some non Intel CPUs.


Marcel

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

#1522

 > And it sadly fails on some non Intel CPUs.

Only optimize if you have to, without introducing avoidable implicit 
requirements. Don't optimize "because it's faster/cool". Ignoring 
Mozilla's latest SSE2 restrictions, a Pentium II is a good bottom line
for FF/SM/TB because of the installable memory, but not because of the
CPU.

I'ld recommend to use a compier's default, without having to document 
the requirements. If each 1% may count (video, mdern browser, and so 
on)(, then try to select a Pentium II. If you're requiring a CPU newer
than a Pentium 4, then you've lost most of the OS/2 
community.Silently. In most of the world's languages there's no such 
thing as OS/2/eCS for modern hardware.


--

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

#1525

A.D. Fundum wrote:
>   > And it sadly fails on some non Intel CPUs.
>
> Only optimize if you have to, without introducing avoidable implicit
> requirements. Don't optimize "because it's faster/cool". Ignoring
> Mozilla's latest SSE2 restrictions, a Pentium II is a good bottom line
> for FF/SM/TB because of the installable memory, but not because of the
> CPU.
>
> I'ld recommend to use a compier's default, without having to document
> the requirements. If each 1% may count (video, mdern browser, and so
> on)(, then try to select a Pentium II. If you're requiring a CPU newer
> than a Pentium 4, then you've lost most of the OS/2
> community.Silently. In most of the world's languages there's no such
> thing as OS/2/eCS for modern hardware.

I'd argue that many people have something newer then a P4 though I 
wouldn't target anything newer except as an alternative.
IIRC, even a PII supports more instructions then an Athlon, though on 
the other hand, an Athlon has 3DNOW! which is similar to SSE and an 
example of something that has gone away.
The big advantage of targeting i686 is aligning the instructions on word 
boundaries, which should benefit most all newer CPU's
Dave

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web