f



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.
0
David
10/22/2016 4:49:08 PM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

59 Replies
392 Views

Similar Articles

[PageSpeed] 48

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)

0
Doug
10/22/2016 5:32:12 PM
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
0
Dave
10/22/2016 5:48:37 PM
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
0
Dave
10/22/2016 6:02:41 PM
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
0
Marcel
10/22/2016 7:54:52 PM
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
0
Marcel
10/22/2016 7:58:02 PM
 > 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.


--
0
A
10/22/2016 9:47:15 PM
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?

Cheers,

Paul

0
Paul
10/23/2016 1:19:17 AM
Marcel Mueller wrote:
> 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.

That's true, but if targeting i486, why not target i686? I started 
targeting i686 during the Mozilla 10ESR cycle and have yet to have a 
complaint about sigills or anything similar. Seems that most every OS/2 
user has something that handles i686 instructions though there are 
questions about things like cmov, which is fast on some processors and 
really slow on others. Not sure if GCC uses cmov when targeting i686.

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

Interesting, do you know of any examples?
>
>
>> 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.

Do you mean ones like Athlon that never supported SSE? Anyways I'd 
generally stick to something like i686 if distributing and perhaps also 
add something that targeted newer CPU's such as the couple of test 
builds of SM and TB I did.

Dave
0
Dave
10/23/2016 3:00:50 AM
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
0
Dave
10/23/2016 3:05:37 AM
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

0
Dave
10/23/2016 3:11:06 AM
 > That's true, but if targeting i486, why not target i686?

Why target i686? Typically you'll have to document it, because OS/2 is
i386+. Or rename a product to "... for eCS". eCS is i686+.

 >  I started targeting i686 during the Mozilla 10ESR cycle
 > and have yet to have a complaint about sigills

Mozilla is the best example why a i686 can be a good target, because 
browsing with a i486 would be "insane". But there's no reason why a 
CONFIG.SYS sorter should target the i686 family.

 > Seems that most every OS/2  user has something that handles
 > i686 instructions

You'ld use older $5 hardware for specific apps which have stopped 
working, for example due to required old native video drivers.

If using involves browsing of third-party websites, then a i686 is the
bottom line because of the installable memory. If a i686 would be the 
default of GCC, then remaining users won't complain indeed, and owners
of old hardware will be familiar with such a PITA.

OTOH I'm not using the latest FF due to the assumed eCS 2.x 
environment, so I've left your Mozilla for OS/2 community "silently".

In a nutshell, a 386 is the best default target. Same as the OS. 
That's why. Otherwise it should be documented as a specific 
requirement. If your users are probably using a modern browser, 
including video, and your app requires power (video) or each 1% counts
(video), then a i686 can be a documented option. You won't even use a 
i686 to watch a video. If you assume the use of anything newer than a 
Pentium III, then people will leave your community silently. If the 
developer assumes the use of at least two cores, then even more people
will leave the community silently. FF49+ requires a Pentium 4 or 
newer. AFAIK the latest FF for OS/2 assumes eCS 2, which comes down to
reducing the community too.

In 99.99% of all cases, rounded up to 100%, I won't notice the use of 
a i686 setting. I may not be aware of a marginal speed gain, and I'll 
be using a i686+. Hence no complaints. But programmers should document
it, because the technical bottom line of the environment is OS/2's 
386. Unless the use of a i686+s bleedin' obvious, like a browser which
requires a little bit more RAM than the 32'ish MB of a 486. The 
required memory requires a i686 or newer. FF38 works with a i686 CPU 
or with a Pentium 4.

Or stop writing software for OS/2 and finally start writing software 
for eCS. eCS comes down to i686+, and users of OS/2 Warp 4 FP9  will 
be aware of restrictions, including possibly required APIs. An 
acceptable bottom line of OS/2 FP versions is the Y2K FP. 

BTW, internet services which require a registration of users to report
bugs will also reduce the number of complaints.


--
0
A
10/23/2016 8:46:26 AM
 > many people have something newer then a P4 though
 > wouldn't target anything newer except as an alternative.

The latest FF assumes an eCS 2.x environment, which you'll have to buy
for anything newer than a Pentium 4.

 > The big advantage of targeting i686 is aligning the instructions
 > on word boundaries, which should benefit most all newer CPU's

So start writing software for eCS. AFAICT this always implies the use 
of a i686+. The remaining users of OS/2, including the well-known and 
appriciated Korean FP15 example, will be aware of possible problems.

With a "SeaMonkey for eCS", the bottom line is a i686. But please use 
386 as a target for a CONFIG.SYS sorter for OS/2. Typically I'll use 
the default setting of VAC, a 386, despite of the fact that even I 
don't have a 386. AFAIK the installer of eCS requires a i686, so eCS 
is a clear generic threshold and it implies the use of a i686+ CPU.

If your software assumes an eCS  2 environment (YUK installer, and so 
on), then "SeaMonkey for eCS 2" will be better and clear. Lenovo is 
the threshold. All of my OS/2 or eCS hardware in use is still IBM, 486
upto and including a Pentium 4. I'm still waiting for a translated eCS
2+...

The bottom line of  M$ Windows updates with FF49+  updates 
(SSE2-related) is a Pentium 4. The main reasons why I won't complain 
about a FF49 for eCS 2.x+ (i.e. a eCS 2.x environment) is because ... 
I'm not using it. 

Anyway, I'ld suggest to use a compiler's default target. If it has a 
real use, then target a i686 (100% CPU load, video, significant speed 
gains), then perhaps rename your product to "<name> for eCS". But 
please don't target a i686 just because you've studied and understood 
compiler switches without a significant gain.


--
0
A
10/23/2016 9:08:46 AM
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.

0
Lars
10/23/2016 10:56:56 AM
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
>

0
David
10/23/2016 4:20:57 PM
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.


0
David
10/23/2016 4:35:43 PM
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.

0
David
10/23/2016 4:45:03 PM
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
0
Marcel
10/23/2016 5:32:26 PM
A.D. Fundum wrote:
>   > many people have something newer then a P4 though
>   > wouldn't target anything newer except as an alternative.
>
> The latest FF assumes an eCS 2.x environment, which you'll have to buy
> for anything newer than a Pentium 4.

The latest FF, which Bitwise compiled to target a i486 due to the need 
for the GCC atomics, runs fine on my OS/2 ver 4+fp15 system though with 
only one core working on my C2D.
At that my first C2D system was a P4 until I replaced the CPU. The 
1.86Ghz C2D was almost twice as fast as the 2.8Ghz P4. I did end up 
buying eCS2.1 so I could take advantage of both cores as Warp V4 has too 
many none SMP safe libraries.

>
>   > The big advantage of targeting i686 is aligning the instructions
>   > on word boundaries, which should benefit most all newer CPU's
>
> So start writing software for eCS. AFAICT this always implies the use
> of a i686+. The remaining users of OS/2, including the well-known and
> appriciated Korean FP15 example, will be aware of possible problems.

I target my Warp V4+fp15+other free fixes such as the 32 bit stack.

>
> With a "SeaMonkey for eCS", the bottom line is a i686. But please use
> 386 as a target for a CONFIG.SYS sorter for OS/2. Typically I'll use
> the default setting of VAC, a 386, despite of the fact that even I
> don't have a 386. AFAIK the installer of eCS requires a i686, so eCS
> is a clear generic threshold and it implies the use of a i686+ CPU.

IIRC, even the later refresh of Warp V4 needs an i486 to install, or 
perhaps that was Warp Server.

>
> If your software assumes an eCS  2 environment (YUK installer, and so
> on), then "SeaMonkey for eCS 2" will be better and clear. Lenovo is
> the threshold. All of my OS/2 or eCS hardware in use is still IBM, 486
> upto and including a Pentium 4. I'm still waiting for a translated eCS
> 2+...

Are you using the 486? I'd assume that it wouldn't support enough memory 
to run Mozilla.

>
> The bottom line of  M$ Windows updates with FF49+  updates
> (SSE2-related) is a Pentium 4. The main reasons why I won't complain
> about a FF49 for eCS 2.x+ (i.e. a eCS 2.x environment) is because ...
> I'm not using it.
>
> Anyway, I'ld suggest to use a compiler's default target. If it has a
> real use, then target a i686 (100% CPU load, video, significant speed
> gains), then perhaps rename your product to "<name> for eCS". But
> please don't target a i686 just because you've studied and understood
> compiler switches without a significant gain.
>

Generally when I port something, I do target the default i386 unless 
there is a reason to target newer. Atomic operations is one reason I've 
been forced to target newer. The atomic code is needed to make sure only 
one thread accesses a data structure at a time. Especially important in 
a SMP system and there are i686/PII SMP systems out there that can run 
Warp Server 2.1SMP.
Dave

0
Dave
10/23/2016 5:33:12 PM
A.D. Fundum wrote:
>   > That's true, but if targeting i486, why not target i686?
>
> Why target i686? Typically you'll have to document it, because OS/2 is
> i386+. Or rename a product to "... for eCS". eCS is i686+.

WarpV4.5, aka FP13+, needs at least a 486SX and some kernels were broken 
and needed a 486.
Is anyone using Warp V4 FP12 or Warp V3? At least for general use.

>
>   >  I started targeting i686 during the Mozilla 10ESR cycle
>   > and have yet to have a complaint about sigills
>
> Mozilla is the best example why a i686 can be a good target, because
> browsing with a i486 would be "insane". But there's no reason why a
> CONFIG.SYS sorter should target the i686 family.

You're right about the CONFIG.SYS sorter and If I was compiling one, I'd 
use the defaults.
Note that according to the readme from the later kernels, an i686 
(Pentium Pro) is required to access more then 64MBs of memory using the 
int15 func e820 to avoid problems on older CPU's.

>
>   > Seems that most every OS/2  user has something that handles
>   > i686 instructions
>
> You'ld use older $5 hardware for specific apps which have stopped
> working, for example due to required old native video drivers.

How many are using such old hardware and need to run new binaries?
I'm also pretty sure that most developers would build a 386 version on 
request. I know I would.

>
> If using involves browsing of third-party websites, then a i686 is the
> bottom line because of the installable memory. If a i686 would be the
> default of GCC, then remaining users won't complain indeed, and owners
> of old hardware will be familiar with such a PITA.
>
> OTOH I'm not using the latest FF due to the assumed eCS 2.x
> environment, so I've left your Mozilla for OS/2 community "silently".

FF runs fine on my Warp V4 (all free updates installed) system, though I 
can only use one core.

>
> In a nutshell, a 386 is the best default target. Same as the OS.

Actually it seems a 486SX is the minimum for Warp V4+fp15

> That's why. Otherwise it should be documented as a specific
> requirement. If your users are probably using a modern browser,
> including video, and your app requires power (video) or each 1% counts
> (video), then a i686 can be a documented option. You won't even use a
> i686 to watch a video. If you assume the use of anything newer than a
> Pentium III, then people will leave your community silently. If the
> developer assumes the use of at least two cores, then even more people
> will leave the community silently. FF49+ requires a Pentium 4 or
> newer. AFAIK the latest FF for OS/2 assumes eCS 2, which comes down to
> reducing the community too.

FF for OS/2 assumes Warp V4 + all free fixes and various ported 
libraries including some that require GCC atomics which use instructions 
introduced with a 486. If you go to about:build on a Bitwise build of 
FF, you'll see they targeted i486 with generic tuning. Some of the 
libraries are only available for i686 but could be recompiled for i486.
While there is code that will take advantage of multiple cores, it is 
not a requirement. Videos and such run fine on my Warp v4.5 system with 
one core.

>
> In 99.99% of all cases, rounded up to 100%, I won't notice the use of
> a i686 setting. I may not be aware of a marginal speed gain, and I'll
> be using a i686+. Hence no complaints. But programmers should document
> it, because the technical bottom line of the environment is OS/2's
> 386. Unless the use of a i686+s bleedin' obvious, like a browser which
> requires a little bit more RAM than the 32'ish MB of a 486. The
> required memory requires a i686 or newer. FF38 works with a i686 CPU
> or with a Pentium 4.
>
> Or stop writing software for OS/2 and finally start writing software
> for eCS. eCS comes down to i686+, and users of OS/2 Warp 4 FP9  will
> be aware of restrictions, including possibly required APIs. An
> acceptable bottom line of OS/2 FP versions is the Y2K FP.
>
> BTW, internet services which require a registration of users to report
> bugs will also reduce the number of complaints.

Unluckily with a lot of bug reporting software, it's hard to avoid the 
registration thing. Even mailing lists need an email address. Personally 
I'll monitor the newsgroups as long as I can.
Dave

0
Dave
10/23/2016 5:58:43 PM
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



0
Dave
10/23/2016 6:06:09 PM
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
>

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
Dave
0
Dave
10/23/2016 6:09:43 PM
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
0
Peter
10/23/2016 7:11:29 PM
 > 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.


-- 

0
A
10/24/2016 9:20:12 AM
 >> The latest FF assumes an eCS 2.x environment

 > The latest FF, which Bitwise compiled to target a i486
 > due to the need for the GCC atomics, runs fine on my
 > OS/2 ver 4+fp15

In general it doesn't. FF + OS/2 = missing DLLs. You had to eCS 2'ify 
your OS/2 system, which requires quite a few extraordinary efforts 
from an user's point of view (the requirements of requirements of 
requirements of requirements of required software). It will work, wehy
not, but I wouldn't sell it as OS/2 software. Your customers will 
complain that they cannot find all DLLs, and the solution to obtain 
those DLLs ... su^G^Gblows. Engineers (it works) vs humans. ;-)

 > I did end up buying eCS2.1 so I could take advantage
 > of both cores as Warp V4 has too many none SMP
 > safe libraries.

I couldn't install eCS 1.2 using an IBM/Lenovo T60p after disabling 
one of the cores. So far that's the only reason why I could consider 
an upgrade to eCS 2 DE/EN. An outdated browser may be the next reason.

 > I target my Warp V4+fp15+other free fixes such as the 32 bit stack.

Please keep in mind that you're one of the happy few, nowadays 
restricted to the most active languages in this thread: DE/EN. FP15 is
not GA. There's no such thing as a GA  Korean FP15 (FP5: 
ftp://service.software.ibm.com/ps/products/os2/fixes/v4warp/korean/fx0
0505).

There's OS/2 (386), there's a Y2K FP (386, we've lost a few OS/2 
languages back then), there are non-GA fixpaks to reduce the number of
OS/2 languages (386), there's eCS 1 (i686+, less languages), and 
there's eCS 2 (i686, DE/EN only).

Hence the suggestion to rename readme.os2 and makefile.os2 to *.ecs, 
to assume the use of a i686+. Users of FP15 will be aware of possible 
problems. A language is a good reason to keep using such an old beast.

Off topic: I'll understand eCS 2 DE/EN, but often that comes down to 
using ELF (English as a Lingua Franca). ELF, we're using it right 
here, is one of the worst solutions. In our case you may have the 
advantage of  native language, but I may be restricted to the 
vocabulary of a child, and my users may not speak English or German at
all.

 > even the later refresh of Warp V4 needs an i486 to install

Retorical: GA, or only a version for the happy few? 

Not retorical: it will be safe to use i486 as the bottom line, but you
should document it. I can recall one newsgroup report of  386 user, 
but that was a museum piece instead of an used computer. Imn other 
words, he owned a 386 but didn't use it for anything. I'm using a 486,
mainly for testing purposes. Nevertheless I'm still not using VAC's 
switch /G4 to target 486, because the gain, if any, requires 
documentation because it isn't a 386.

 > Are you using the 486?

Yes, but of course not frequently. And I'll use Netscape instead of 
FF/SM, if I would have to view a (local) HTML file. Software can stop 
working, and I have even used my 486 to answer a Mozilla's font 
question of Peter Weilbacher, IIRC. It also is one of my three 
Warp-installs (2x 486, 1x 586), the rest is eCS 1.2.

 > I'd assume that it wouldn't support enough memory 
 > to run Mozilla.

A pimped pentium II notebook hardly has enough memory to use the last 
FF/SM for OS/2, and an animated GIF will kill the remaining 
performance. In case of an "emergency" it can be used. Or, for 
example, you may decide that you don't need a $1599 8THz CPU to 
download a large file with a modem.

 > Generally when I port something, I do target the default i386
 > unless there is a reason to target newer.

I think video-related DLLs of FF/SM can target the i586 (supported by 
IBM?) or i686+ (anything "newer than i486"?). The user of an 
unofficial Korean FP15 could still develop it, and it requires hardly 
more than renaming *.OS2 to *.eCS. And a fully working compiler 
switch.

A Pentium 4 is hardly fast enough to watch modern HQ videos. A PIII 
may still work. You don't grab a PII to watch a video.

Off topic:iIt would help if I was able to disable the second core and 
use newer hardware than 10+ years old Pentium IIs-4s, but the eCS 1.2 
installer seems to stop after displaying the blue eCS logo and after 
disabling the second core.


--
0
A
10/24/2016 10:36:53 AM
 > Is anyone using Warp V4 FP12 or Warp V3?
 > At least for general use.

Wrong question, FP12 is not GA, i.e. not "general". See my other post,
you're one of the happy few and we've lost most of the other people. 
Silently. The last GA Korean FP is FP5. GA FP milestones are  Warp 4 
("FP0", all languages) and the Y2K fixpak (some languages).

As mentioned elsewhere, nobody will be actually using a 386. I can 
reall one case, and "general use" wasn't true. He just owned an old 
beast which still worked: 100% museum. Warp 4 may be in use by people 
not speaking English that well, so they may never read our text here.

 > Note that according to the readme from the later kernels,
 > an i686 (Pentium Pro) is required to access more then
 > 64MBs of memory using the int15 func e820 to avoid
 > problems on older CPU's.

Probably confirmed: I wasn't able to install eCS using an ancient 
ThinkPad 760EL with 80 MiB, so I've installed Warp 4 instead. I'm not 
use if I skipped Pentium Pros.

 > How many are using such old hardware and need to run new
 > binaries?

Technology isn't democracy. A few users? "need" is a bit of a stretch.
Some CONFIG.SYS sorter can be a new binary. Last time I may have used 
a new UNZIP.EXE to extract an IBM EWS drawing app, which wouldn't work
anymore with any newer OS version. Without having to contatc the autor
of UNZIP.EXE for OS/2 to verify if it's OS/2 software.

 > most developers would build a 386 version on request.

I'm willing to advocate a 486 as the bottom line, but you'll have to 
document it if you're writing software for OS/2. OS/2 = old = 386.

In general writing software for eCS addresses all of the above. 

 >> In a nutshell, a 386 is the best default target. Same as the OS.
 
 > Actually it seems a 486SX is the minimum for Warp V4+fp15

Again, I'm assuming GA versions. And, sometimes, my point of view is 
the point of view of an user. The requirements of requirements of 
requirements of requirements of requirements of FF are Unix-solutions,
without keeping OS/2 in mind. Or it are eCS 2.x users, using DE or EN 
as their language (and already having YUK/RUM). Over here I'm the 
package manager, an announced translated version of eCS 2.x isn't 
available yet, and  "non-old" hardware isn't an option. Unfortunately,
Actually it's a problem that most of my hardware is 15'ish years old.

 > I'll monitor the newsgroups as long as I can.

O, I know. Bless you. Over here most ISPs won't even offer Usenet 
anymore. Even my email may stop working, according to a rather old 
annoucement of my ISP (former ibm.net). 


--
0
A
10/24/2016 11:04:57 AM
 > I'm also pretty sure that most developers would build
 > a 386 version on request. I know I would.

FWIW, my informal proposal to start writing software for eCS (Pentium 
Pro+) and eCS 2 (YUK/RUM) reverses this. 

Write a CONFIG.SYS sorter for eCS. Users of OS/2, if any, will be 
aware of that. If it doesn't work, then they could request an OS/2 
version. By default it's software for eCS, so users of OS/2 have to be
"lucky" (availability of APIs/Warp v4.5/FPOs, and so on). The 
developer has the freedom to assume the use of a i686+, without having
to document anything.

Technically "FF for OS/2" may still work, I won't even try to argue 
with the educated expert, but "FF for eCS 2.1('s environment)" does 
not rule out that OS2 and eCS 1.x are still supported too. It may be a
PITA, but it'll work.


--
0
A
10/24/2016 11:24:00 AM
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)

0
Doug
10/25/2016 4:50:17 PM
A.D. Fundum <what.ever@neverm.ind> wrote:
>  >> The latest FF assumes an eCS 2.x environment
> 
>  > The latest FF, which Bitwise compiled to target a i486
>  > due to the need for the GCC atomics, runs fine on my
>  > OS/2 ver 4+fp15
> 
> In general it doesn't. FF + OS/2 = missing DLLs. You had to eCS 2'ify 
> your OS/2 system, which requires quite a few extraordinary efforts 
> from an user's point of view (the requirements of requirements of 
> requirements of requirements of required software). It will work, wehy
> not, but I wouldn't sell it as OS/2 software. Your customers will 
> complain that they cannot find all DLLs, and the solution to obtain 
> those DLLs ... su^G^Gblows. Engineers (it works) vs humans. ;-)

Make a statically linked version?

-- 
Pete
0
Peter
10/25/2016 8:53:23 PM
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.


0
David
10/26/2016 3:37:35 PM
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
---------------------------------------------------------------------
0
Steven
10/26/2016 6:44:18 PM
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)

0
Doug
10/26/2016 7:15:23 PM
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
---------------------------------------------------------------------
0
Steven
10/26/2016 8:44:45 PM
 >>  FF + OS/2 = missing DLLs. You had to eCS 2'ify  your OS/2
 >> system, which requires quite a few extraordinary efforts from
 >> an user's point of view (the requirements of requirements of 
 >> requirements of requirements of required software).

 > Make a statically linked version?

That was discussed in comp.os.os2.apps, and I'm not expecting that 
Dave will release a fully statically linked SM version of BWW's FF for
an eCS 2.x environment. IIRC he has already reduced the number of 
required DLLs in the past, but as such FF is BWW's impressive project.

Releasing the DLLs as "RPM" ZIP files could work too, to offer people 
an alternative way to manage their own packages, but apparently 
"unification" was more important than users.

FWIW, BWW has complained ("press release") that people have to contact
them. I'm not using eCS 2.x DE/EN nor an eCS 2.x environment, I'm not 
using the FF for OS/2 in question (because of their excessive 
requirements), and I tend to not create accounts to report or discuss 
RFCs, policies and bugs.


--
0
A
10/27/2016 8:49:21 AM
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


0
Paul
10/27/2016 9:00:35 AM
A.D. Fundum wrote:
>   >>  FF + OS/2 = missing DLLs. You had to eCS 2'ify  your OS/2
>   >> system, which requires quite a few extraordinary efforts from
>   >> an user's point of view (the requirements of requirements of
>   >> requirements of requirements of required software).
>
>   > Make a statically linked version?
>
> That was discussed in comp.os.os2.apps, and I'm not expecting that
> Dave will release a fully statically linked SM version of BWW's FF for
> an eCS 2.x environment. IIRC he has already reduced the number of
> required DLLs in the past, but as such FF is BWW's impressive project.
>
> Releasing the DLLs as "RPM" ZIP files could work too, to offer people
> an alternative way to manage their own packages, but apparently
> "unification" was more important than users.

There are zips of most of the packages available and unrpm is also 
available to extract the files. They do use @UNIXROOT, which makes sense 
as most of the ports don't understand drive letters.

>
> FWIW, BWW has complained ("press release") that people have to contact
> them. I'm not using eCS 2.x DE/EN nor an eCS 2.x environment, I'm not
> using the FF for OS/2 in question (because of their excessive
> requirements), and I tend to not create accounts to report or discuss
> RFCs, policies and bugs.

Yes, while they advertise Mozilla, they're only interested in Firefox. 
It's a shame as once Firefox is compiling, it is not much more work to 
support SM and TB.
Of course they're no longer targeting eCS as Arca Noae is paying them to 
target their coming release. At least Arca Noae is willing to support 
OS/2, eg with a subscription, you can download binaries like ACPI that 
are quite happy to be installed on Warp V4. Only really needed with 
newer machines, mine is right on the cusp and works about the same with 
it or without it, so I have it remmed out currently until my next upgrade.
Dave

0
Dave
10/29/2016 1:01:01 AM
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

0
Paul
10/29/2016 1:09:44 AM
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

0
Dave
10/29/2016 3:54:12 AM
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

0
Dave
10/29/2016 3:56:40 AM
Peter Flass wrote:
> A.D. Fundum <what.ever@neverm.ind> wrote:
>>   >> The latest FF assumes an eCS 2.x environment
>>
>>   > The latest FF, which Bitwise compiled to target a i486
>>   > due to the need for the GCC atomics, runs fine on my
>>   > OS/2 ver 4+fp15
>>
>> In general it doesn't. FF + OS/2 = missing DLLs. You had to eCS 2'ify
>> your OS/2 system, which requires quite a few extraordinary efforts
>> from an user's point of view (the requirements of requirements of
>> requirements of requirements of required software). It will work, wehy
>> not, but I wouldn't sell it as OS/2 software. Your customers will
>> complain that they cannot find all DLLs, and the solution to obtain
>> those DLLs ... su^G^Gblows. Engineers (it works) vs humans. ;-)
>
> Make a statically linked version?
>

It has become hard. Some libraries (fontconfig and pango) seem to be 
designed to be shared, some don't work statically linked (mmap, where I 
got socket errors when statically linked) and some are only getting 
fixed in the YUM/RPM environment (NSPRPUB and the NSS DLLs). As well 
some of the shared libraries have the same dependencies as Mozilla, 
namely cairo and its requirement of pixman. Seems easier and safer to 
use the same DLL rather then statically linking 2 different versions. 
Get fixes and speedups with the newer version as well.
Then a bunch of the libraries need rebuilding and the license says I 
need to distribute the source and I have a shortage of bandwidth. 
Ideally I'd have to fork the Bitwise port of Firefox as well as a bunch 
of the dependencies.
Dave
0
Dave
10/29/2016 4:07:21 AM
A.D. Fundum wrote:
>   > I'll monitor the newsgroups as long as I can.
>
> O, I know. Bless you. Over here most ISPs won't even offer Usenet
> anymore. Even my email may stop working, according to a rather old
> annoucement of my ISP (former ibm.net).

My ISP dropped newsgroups a long time ago. I ended up spending $10 for a 
couple of GBs with no time limit. It'll last my lifetime with my use.
Now my ISP has announced that they're dropping dial-up on Nov 16. 
Dial-up is the only option where I live, don't even have cell coverage 
(sometimes a little bit in one spot upstairs) and the mountains hide the 
satellites.
I'll be left with cell coverage and wifi in town and cellular internet 
is $1 for 10MBs with 15 cents a MB if I go over, Or $70 for a GB. Canada 
is probably the worst country in the world for internet and cell.
I guess I'll be using my T42 a lot more.
Dave
0
Dave
10/29/2016 4:28:34 AM
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.

0
David
10/29/2016 12:37:38 PM
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.
0
David
10/29/2016 1:41:33 PM
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
0
Dave
10/29/2016 6:43:47 PM
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)

0
Doug
10/29/2016 10:22:54 PM
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

0
Paul
10/30/2016 1:43:12 AM
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.
0
David
10/30/2016 7:57:11 AM
 > unrpm is also available to extract the files.

Retorical: most files, not all files? I'll look at it again after a 
new major upgrade, albeit most of my hardware probably won't support  
FF49+ anyway (SSE2-related, FF49 for Windows requires a Pentium 4+).

 > They do use @UNIXROOT

To be fair, the main problem of a real Unix directory structure is 
that I don't have it (free boot disk space may become a problem too). 
There's no "Unixification Package for OS/2 and eCS 1.x". OTOH, if I 
would install eCS 2, and eCS 2 would introduce a real Unix directory 
structure (i.e. not an avoidable directory called "@UNIXROOT"), then I
may smile and enjoy my new OS while it's being installed by the 
installer of the OS. IOW: I'll use Unix if I like an Unix directory 
structure, but I wouldn't uninstall it. In the end it's an acceptable 
PITA, if an installer for OS/2/eCS 1.x  installs the basics.

 > Arca Noae is willing to support OS/2, eg with a subscription

Well, as long as it's clear. I'd prefer to use eCS 1.2 (USB support, 
new APIs since my W4 FP9) and rather old "new" hardware (T60p, too 
many cores, apparently even after disabling all but one core). At the 
moment that's my best theoretical combination, but now I cannot even 
install eCS 1.2. What I want/need is quite clear, from an user's point
of view. eCS 2.x works, but all I've seen is the demo CD.


--
0
A
10/31/2016 1:14:19 PM
 > mountains hide the satellites.

I've pressed <F5> a few times during one of your Hobbes uploads...

 > Canada is probably the worst country in the world
 > for internet and cell.

I'll reconsider a commercial CD/DVD/USB large file download/upload 
service, and sneak you in as a mandatory XTS (virtual test currency) 
test account for the Canadian franchisee.


--
0
A
10/31/2016 1:49:25 PM
A.D. Fundum wrote:
>   > unrpm is also available to extract the files.
>
> Retorical: most files, not all files? I'll look at it again after a
> new major upgrade, albeit most of my hardware probably won't support
> FF49+ anyway (SSE2-related, FF49 for Windows requires a Pentium 4+).

Looks like FF52ESR will also be the last to support Win XP (and Vista) 
though they are talking about extending the ESR support past the usual 1 
year if the number of user is high enough.

>
>   > They do use @UNIXROOT
>
> To be fair, the main problem of a real Unix directory structure is
> that I don't have it (free boot disk space may become a problem too).
> There's no "Unixification Package for OS/2 and eCS 1.x". OTOH, if I
> would install eCS 2, and eCS 2 would introduce a real Unix directory
> structure (i.e. not an avoidable directory called "@UNIXROOT"), then I
> may smile and enjoy my new OS while it's being installed by the
> installer of the OS. IOW: I'll use Unix if I like an Unix directory
> structure, but I wouldn't uninstall it. In the end it's an acceptable
> PITA, if an installer for OS/2/eCS 1.x  installs the basics.

Run ANPM (freely available from the Arca Noae site) and it'll install 
the basic @UNIXROOT stuff on its first run. Runs on at least Warp V4 
fp15 and perhaps earlier (untested).

>
>   > Arca Noae is willing to support OS/2, eg with a subscription
>
> Well, as long as it's clear. I'd prefer to use eCS 1.2 (USB support,
> new APIs since my W4 FP9) and rather old "new" hardware (T60p, too
> many cores, apparently even after disabling all but one core). At the
> moment that's my best theoretical combination, but now I cannot even
> install eCS 1.2. What I want/need is quite clear, from an user's point
> of view. eCS 2.x works, but all I've seen is the demo CD.

The subscription would also support eCS 1.2 though you'd have to add 
ACPI to the boot disks I guess.
Lars has uploaded his recent USB support to Hobbes, worth trying.
Dave

0
Dave
10/31/2016 2:59:01 PM
 > Run ANPM (freely available from the Arca Noae site)
 > and it'll install the basic @UNIXROOT stuff on its first
 > run.

Thanks, worth a try to upgrade this "OS component".

 > The subscription would also support eCS 1.2

A good T23 died this morning, so I've posted an article in c.o.o.e 
with questions to install eCS 1.2 (in theory Warp 4 is possible too). 
Certainly not my last PIII, but the number of perfectly working faster
(>= 1 GHz) PIIIs now is 0. It looks like I have to update a few files.
I'm not sure if ACPI is involved, it's one of the oldest IBM/Lenovo 
T60s (i.e. not a 100% Lenovo).


--
0
A
11/1/2016 1:46:06 PM
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.


0
David
11/1/2016 4:47:48 PM
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)

0
Doug
11/1/2016 7:18:19 PM
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
---------------------------------------------------------------------
0
Steven
11/10/2016 1:36:20 AM
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
---------------------------------------------------------------------
0
Steven
11/10/2016 1:38:31 AM
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
---------------------------------------------------------------------
0
Steven
11/10/2016 1:54:36 AM
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

0
Dave
11/10/2016 4:52:30 PM
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
---------------------------------------------------------------------
0
Steven
11/11/2016 4:41:54 PM
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

0
Dave
11/12/2016 1:04:29 AM
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.


0
David
11/12/2016 1:48:27 PM
Reply: