Re: improve strlen

hmmmm,

For someone who has chosen to troll in an x86 assembler forum for C++
programming, I sugest that the only person you have convinced is
yourself as most programmers in the assembler market have heard all of
this stuff before.

> >I sugest that you have probably spent more time than it would take to write it
> >in assembler and while the development may be useful to you in terms of
> >portability, it is neither a development time or speed advantage.
>
> Interesting hypothesis, what's it based on?

Your response time.

> >In my youth I wrote ANSI C but time and cynicism lead me down the road
> >of writing pure assembler in many places because portability in almost
> >every instance is a myth. My main use for a C compiler these days is
>
> It's a myth only to someone who never has to do it.

For a combined market share of about 2%, who cares.

> >don't properly understand that assembler can routinely work with the
> >12000 plus API calls, the near massive collection of compatible C
> >libraries, libraries written in assembler and so on.
>
> That's their problem.

Its also its advantage when such a massive range of functionality is
available apart from what they write themselves. Try writing Windows
software with a C compiler without the library support and you will do
it harder and slower than an assembler.

> >Instruction choice is a matter of targetted market width. If the Linux
> >desktop market is 2%, gaming is 0.01% of the sum total market and it
> >makes high demands on video, meory and processor performance, all of
> >which change on a weekly basis to a later faster and more expensive
> >choice.
>
> I don't find the prices rising, on the contrary a new hardware is
> cheaper and faster than ever, and the prices of old hardware are diving
> rapidly as we speak aswell.

Speak to people who have problems raising the couple of grand to buy a
later high end box. Try the population of China, Asia generally, a
large number of people in the US, South America, programmers from the
old eastern block in Europe and of course the many very good programers
from Russia. There is a whole world out there without the type of
funding necessary to keep buying high end boxes.

> >I have always been stuck with targetting code at the widest number of
> >people and this means the furthest backwards compatibility for the
> >current Window OS platform. This says primarily 486 code but there is
>
> Out of curiosity, what software is that?

Commercial software is generally written under a non-disclosure
agreement and I still have a few older ones floating around so I cannot
help you with my own history. What I do place for public usage is MASM
code and it is aimed at 486 compatibility.

> >The hallmark of modern application production is massive size
> >increases, reduced functionality, inappropriately used threaded code
> >with endless timing lags and very high demands on current hardware.
>
> Yeah, damn Microsoft!

And damned Borland, damned Linux, damned FreeBSD, damned Sun, SGI and
everyone else who uses C++. :) Nothing like slopping around oversized
underperforming bloated junk to feel profound.

> >This is fine and I hope it was useful to you but with the development
> >time to produce a C++ version that is nearly as fast as an old
> >assembler version, development time goes for the assembler code, not
> >the C++ code.
>
> You happen to know, how long it took Dr. Fog to develop the assembly
> version? I happen to know pretty accurately how long it took to write
> the C++ version.. I'm just guessing here, but I have a reason to
> believe that you know neither.

Interestingly enough he never mentioned it even though he is a member
of our forum but then he is also a very experienced assembler
programmer.

> >whatever else. Apart from speed issues, near complete freedom in terms
> >of architecture has a lot going for it and in the case of MASM, its
> >pre-processor will eat C compilers alive in terms of capacity.
>
> MASM is fine if Windows is all you care about.
>
> >Being able to design your own language free from the claptrap is one of
> >the large advantages in assembler programming.
>
> You meant programming using MASM?

No, I mean what I said in the context of a pre-processor that will eat
C++ compilers alive with its capacity. Prebuilt languages come with
pre-built assumptions where an assembler with a high powered
pre-procesor suffers none of that garbage.

> >Very simple actually, the vast majority of computer around the world
> >are not high end dual core AMD 64 Opterons with > 8 gig of memory but
> >far more humble machines that profit from small fast software written
> >in assembler where the later slow bloated hardware specific stuff just
> >won't run on such boxes.
>
> I would dare to say that your "0.01%" estimate is way unrealistic. I
> don't recall the precise dates so I estimate (googling for precise
> dates would make me look better but I don't care about that).

Yes, it could be .02% but as a maket share, its trivial. Few in the x86
gaming market make any money any more and those that do are at the
corporate level.

> Let's say 386 been around since 1985 or thereabout, that's 20 years.
> Let's say x86 compatible systems with SSE support as standard been
> around since about 2000, that's 5 years.
>
> I find it unbelievable, that in the first 15 years 99.99% of PC's in
> *active use* today would be built, and only 0.01% of PC's in active use
> today would been built after year 2000.
>
> It just sounds totally unrealistic, the market has been expanding, not
> shrinking overall during that time. This means that it's more likely
> than in the last 5 years MORE systems been shipped than in the 6 years
> before 2000.

Put graciously the ass fell out of the computer market with the
collapse of the dot com boom and internationally sales are down. Look
at the number of well known software companies that went out backwards
since 2000 and the various hardware companies that have been taken over
in the last few years and you will forget the idea of a market that
expanded in the same way as it did through most of the 90s. There are a
large number of people who still run old boxes that do what they
require who have little use for the newer stuff, especially as the
later OS versions do little better than 10 year old versions.

Think of DOS boxes, Win95 boxes, old MACS that still slug along
perfectly and you will get some idea of why so many people won't spend
the money to get more problems, bugs and the like.

Regards,

hutch at movsd dot com

.

Relevant Pages

  • Re: Evolution
    ... >> it different from HLL programming? ... inline assembler and larger parts by linking to an assembler ... the macro is from a macro library which you have written a long ... or two instructions if you ...
    (alt.lang.asm)
  • Re: HLA Stdlib v2.2 is now available.
    ... Its a generalization of the whole asm community based on the results of a single man. ... You dont get it. ... Because it is an assembler, and a very good one, showing the way for other spesific assemblers. ... As they both are needed for doing programming, I see no reason to seperate them. ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... Use an array incorrectly in RosAsm, ... And that's one of the reasons HLL programming is generally more ... same applies to assembler speed. ...
    (alt.lang.asm)
  • Re: Future of programming
    ... but again, let's not forget in my opinion the main purpose of programming, ... the more abstract the programming language ... code-generators, or even efficient compilers, which is not the case ... > fastest solution to the problem, then assembler is still needed. ...
    (alt.lang.asm)
  • Re: HLA History
    ... >> sequence of processor instructions to solve a given problem. ... I have written my trivial assembler ... >> programming. ... pupils to learn to write with 10 fingers. ...
    (alt.lang.asm)