Re: improve strlen

/*
Windows platform, portable code is of little value when so much code is
specific to the actual OS.
*/

Most of the code isn't OS specific unless the application is really
trivial.

>I have seen people write portable ansi C style code while running
>directX or Windows specific mutimedia functionality which is simply a

There is nothing wrong with that either, I do this all the time in
DirectX applications:

surface* pic = surface::create("data.zip/test.jpg");

The same code works with OpenGL, X11, etc.. on Linux, Windows, etc. I
don't find that strange at all. I also keep rendering module not too
integrated with rest of the code, I usually use components and build
applications using libraries, some of which, heck, most of which are
portable.

/*
something solid like FreeBSD, it would be in portable ANSI C (not++)
but as I write primarily for current 32 bit Windows, such portability
is a waste of time.
*/

That's what you do, I don't write for specific OS per se, I have a wide
range of software over hardware and platforms I been working on over
the years. This includes mobile graphics chips, game software
(published), graphics chip technology demos for chip vendors.. I'm not
locked to Windows so I don't share the same opinion.

/*
Something that makes me laugh is the assumption that assembler is
written only for immediate code problems where historicaly it has
regularly been used for reusable libraries which generally justifies
*/

You remind me in the young and wild days..

/*
Something that also makes me chuckle is the assumption that if you wait
long enough, someone one day will create a C compiler that can output
code in the same class as hand written assembler but after years of
*/

Wait a second champ, I never said that, I am advocating the thought
that resorting to assembly as First thing is folly. Resorting to it
when there is need isn't.

/*
hearing this nonsense, people who make the effort still outclass a
compiler because there is more to code design that robot software
output.
*/

Ofcourse. But only when it pays off in some ways, makes a difference to
real-world software. strlen() is a good example, where it doesn't make
a didly-doo's difference to real programs performance in most of the
real-world, production software. I only took it into myself to write
the C++ version to validate that my theory, which is forged by years of
practise, is still correct. It still is.

/*
With Windows still controlling somthing like 90% of the desktop market,
considerations of what runs on a PPC or MIPS or SPARC or SOLARIS fits
into the category of "who cares" in most instances.
*/

That depends who you writing software for. If you write it for
yourself, okay. If it is freeware, open source.. who cares where it
runs besides the author, or those who contribute. If it is application
written for a customer, usually they dictate the terms. I write
embedded stuff so platforms change. Sometimes someone wants to put
computations into a cluster. Sometimes... the point is I don't mind
that, I write where the software is needed. That's what I do.

If you are fine with Windows, there's nothing wrong with that.

/*
The basic idea is a good one but as about 5% of computers around the
world could run it, its a mute point where the two algos I have posted
will run on a 486 running OEM win95. I would certainly like the luxury
*/

My basic idea was that why not take advantage of the latest instruction
set extensions when *available* ? When they are detected, use them,
have faster software which I think was the WHOLE POINT to begin with
when writing in assembly, or did I miss something? You write in
assembly just because...? What?

If no SSE, MMX, what not, fall back to generic x86 code that works down
to 386, no problem?

If your point is to make fastest possible code, you take the pains to
write the code in assembly, but then ignore latest instructions
possible on x86 platform what's wrong with the picture?

/*
of being able to write PIV code with SSE3 but with the sheer volume of
older computers still running, it will not be any time soon that this
will happen.
*/

It depends what your audience is. If you write games for instance for
commercial market, go and take a look at minimum requirements on the
game boxes. Most of the games don't run on 386 anymore. Just an example
of one market segment.

I don't know why you still want to support 386 while writing *windows*
software in 2005.

/*
One of the good things when 64 bit x86 gets going in the next few years
is that there will be a far more modern instruction set where 10 year
old compatibility is not an anchor around your neck.
*/

I don't see how that is supposed to fit your point of view where
MMX/SSE is too modern already. Explain?

.

Relevant Pages

  • Re: So are we ever gonna see .NET framework 2.0 on Mac or Linux?
    ... want, will have portability issues, regardless of the development platform. ... the extreme to prevent Microsoft from making it work better on Windows. ... Actually, for server side stuff at the very least, Java's portability ...
    (microsoft.public.dotnet.general)
  • Re: Migrating Matlab files from Windows to UNIX
    ... Matlab version 7 now gives priority to user m ... Programmers who use UNIX seldom need ... programs developed for windows. ... UNIX programmers are also very aware of program portability. ...
    (comp.soft-sys.matlab)
  • Re: ADTPro beta available
    ... That's not the way I define portability. ... whose bug is it if a Java application fails to ... of the Java platform on the non-functioning system. ... it only runs on Windows. ...
    (comp.sys.apple2)
  • Re: The illusion of "portability"
    ... Portability for them means the least common denominator. ... on one platform can be expected to behave the same on any other ... Solaris, and Windows 3.1). ... Portability for Windows is a delicate topic, for which the documentation of the natives offers you little to no help. ...
    (comp.lang.c)
  • Re: Iczelions tutorials revisited.
    ... >> For reference I'll just repost the original statements: ... it's an illusion that works. ... > Portability is more than just at the level discussed here. ... > between Windows and Unix is just about complete. ...
    (alt.lang.asm)