Hi,
On Sun, May 5, 2013 at 11:01 AM, Louis Santillan <lpsan...@gmail.com> wrote:
>
> Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles. Read
> (ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
> 2.3.x & 3.5. Enlightening and disappointing. There does not seem to be a
> way to get 32-bit instructions out of wcc as Tom had mentioned.
I don't think wcc.exe was ever meant to output 32-bit code. Granted,
as mentioned previously, it will do some things ("movsx"), but
apparently it doesn't use the extended 32-bit registers.
Though, again, call me cynical, but outside of just reordering
instructions, I don't think this will speed up anything much. Even
then it might just be too trivial. (This is a very difficult and
arcane skill. It's hard to accuse compilers of being dumb when it's an
endless void.) You'll probably get much faster speeds just from using
select (386+) software: UIDE, RDISK, XMGR, HDPMI32, etc.
In fact, I know this is far from exhaustive, but one of the only
things I remember people complaining about (re: speed) was "COPY", but
that's the shell, not the kernel.
> 3.5 recommends
>
> "The recommended options for generating the fastest 16-bit Intel code are:
> Pentium Pro, Pentium, 486, 386, 286, 186, 8086
The real problem is that you can't dynamically adjust such things in
config files. You have to rebuild the compiler to tell it what to do.
Granted, that's probably a goofy idea anyways, maybe not realistic,
but my point is that we're far far from (old) PPro days. Every
subarchitecture (ahem, P4) breaks some previous optimizations and adds
new ones. Last time I (very briefly) read up on some AMD doc, it
mentioned several things that contradicted what was good for 486. So
you can't win for trying.
In fairness, GCC "-mtune=generic" seems to be a moving target
(although originally close to same as "i686") for commonly available
cpus. So I assume things like Pentium 4, Core 2 are good fodder for
that.
> -ot of -onatx & -zp8 contradict the original makefile's code -os & -zp1
> (optimize execution time vs. executable size & align on byte vs. 8-byte,
> respectively). Also, the -fp*'s opts don't apply and wcc barfs on -oi+.
Sometimes it's actually faster to be smaller, but some cpus are overly
sensitive to alignment, hence "-zp8". I think for most x86 cpus
everything is faster when aligned except when overflowing the prefetch
/ cache / pipeline / whatever.
BTW, I remember reading -oa isn't strict ANSI. Not sure if that
matters here, but for general use probably worth avoiding. (IIRC, -ox
is the same as -obmiler -s. Common wisdom says "-otexan" but my latest
preference is just "-otxn". You can "set WCL=", but I don't really
recommend it.)
Default for OpenWatcom is halfway between -os (space) and -ot (time),
so you have to do something like -od (IIRC) to turn off optimizations
completely.
> So in mkfiles\watcom.mk I added some code to add -6-onaxlkh-ei (for 686).
> This will reorder instruction significantly and replace some call nears with
> jmps in a comparison of 386 timed code vs. 686 timed code. Code is larger
> on the 686 side.
Larger before or after UPX?
> So far, not very impressed with OW 1.9's optimizer. Rather minimal
> improvements.
You mean compared to, what, 1.8? Of course I don't personally expect
any improvements, honestly. Somebody would have to really care, and
even a weirdo like me has to admit there is little benefit (outside of
just scratching an itch) as cpus change too fast.
> Anybody play with BCC 5.5 & HX-DOS recently?
That's barely newer than Watcom 11.0, so I doubt it's much better, but
who knows. IIRC, it did support 586, but I don't have it installed
(and too lazy to re-sign up at Embarcadero). BTW, I assume you know it
doesn't support 16-bit (nor any) DOS output, and thus can't compile
the kernel. Sure, you can use WDOSX, but honestly, it's easier just to
use native DOS tools, e.g. DJGPP (4.8.0 ftw!) or OpenWatcom.
(I have not followed latest developments with OW pre-2.x since Google
Groups stopped mirroring it. I assume they are still working on it.
There was some fork's snapshot a while back, but I never tried it due
to not need and no idea what was changed. New maintainer, more
interest in Fortran and other OSes ... beyond that, dunno.)
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
