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

#1528

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


--

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

#1534

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

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

#1540

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


--

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

#1544

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

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

#1549

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


--

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

#1555

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

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

#1563

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


--

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

#1565

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

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

#1566

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


--

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

#1554

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

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

#1524

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

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

#1527

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


--

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

#1535

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

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

#1541

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


--

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

#1556

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

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

#1564

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


--

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

#1542

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


--

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

#1523

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

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

#1526

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

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

#1537

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

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

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

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

csiph-web