Re: LuxAsm questions

• Previous message: snpphakel: "Re: understanding speed"
• In reply to: f0dder: "Re: LuxAsm questions"
• Next in thread: f0dder: "Re: LuxAsm questions"
• Reply: f0dder: "Re: LuxAsm questions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 24 Jun 2004 18:50:11 +0100

f0dder wrote:
> Beth, when timing stuff, you should discard all but the
fastest
> results, as this will show the best possible you can achieve
by the
> code, and will not be affected by the (sometimes wild)
fluctuations you
> can get under a protected mode OS. (Yes, the timing method can
be
> discussed to death and is a religions matter, but consider
running
> averages - if one run, for some reason, has a disk access, it
can skew
> the results massively.)

Indeed; It can be discussed to death...but it all depends _WHAT_
you're timing and measuring...in statistical analysis, you NEVER
take a single data point like this...indeed, the real problem
was more that I did not take _enough_ measurements...if a disk
access had happened which massively skewed the result then this
would have differred substantially from all the other results
and can be excluded from the calculation on the grounds that it
is an "outlier"...

Plus, another point about statistics: _presentation_ is half the
battle...I envisaged that the results might be challenged by an
"anti-INT 80h" advocate...so I made all my "rounding up" go in a
_negative_ direction and showed two sets of results to
demonstrate that I had executed the tests numerous times (that,
indeed, it was NOT a case that a "disk access" had just happened
to occur while the "C-level" test was running and the "INT 80h"
had been disk access free...a demonstration that the values I
was concluding from were _typical_ results from running these
tests), just to make clear that there was no "bias"...

If you don't quite get the need to do that, then check out
previous (and one current) "RosAsm is x20 faster than MASM",
"RosAsm is x3 faster", "RosAsm is x9 times slower", etc., etc.
threads...also, of course, due to "group affliation" with
LuxAsm, one could also think I might try to "make" INT 80h
perform better...

But the final and most important bit: It was NOT meant to be
scientific...the sole thing I was particularly concerned about
finding out was _just_ "is INT 80h the more direct route?" (on
the presumption that the fastest will also be the most
direct)...the actual _times_ are immaterial in this
case...interesting to know by how much for informational
purposes...but, regards LuxAsm, the only question to be answered
really was: "INT 80h or not?"...that's why I didn't conduct it
in anything more than a "rough test" manner...

> Also, consider _what_ you're timing. A call like time is bound
to have
> _very_ little code, and thus call overhead can chew up a
measurable
> amount of time.

No, you misunderstand completely...it's the _CALL OVERHEAD_ that
I'm most concern to get a feeling for...indeed, if there was a
"NOP" system call that _ONLY_ had the usual "call overhead" and
returned immediately then that would be the _PERFECT_
choice...it was _ONLY_ "call overhead" that was of any
consequence...this was ALL we were concerned to time...

This might be unusual for your typical timing purposes but the
actual measure of time here was insignificant...I was comparing
_relative_ timings between "INT 80h" and "C-level"...the "INT
80h" call was consistently faster...the actual functions called
were _identical_ functions, remember...just two different ways
in to access the same syscall...the code inside the actual
kernel for this will be identical...

Indeed, I was - as should be done - trying my best to _ISOLATE_
the only difference between the two calls was _ONLY_ "call
overhead"...or, at least, as best as possible considering it was
a rough, simple test...

> But how often do you call the kernel for such simple
> tasks? You should consider measuring the overhead from
syscalls like
> disk I/O, process creation, IPC, and other things that are
complex, and
> get called a lot more than time.

No; You're not quite getting what I was measuring...I'm not
timing Linux itself in any way (what would be the point? We're a
"Linux assembler"...that part is already decided and fixed
("political", not technical reasons)...whatever results could be
discovered that way, LuxAsm will still be a Linux assembler
primarily ;)...

Indeed, I was attempting to _ISOLATE_ merely the difference in
"call overhead" between the two...and it was a _relative_
measurement - which method is consistently faster - so the
_actual figures_ themselves were somewhat irrelevent
(interesting to know but NOT the purposes of the tests, which
was only to "yay" or "nay" the suspicions about using "INT 80h"
for a more direct route to the syscall services)...

But, by all means, feel free to time such things, if you
want...I believe you've misunderstood what is being measured and
are not selecting the right method of isolating results...so,
please do it and you should discover that the same results come
out, in the end, regards the difference in "call overhead"
between the two...it wouldn't be a waste of time in that it
would _ensure_ - using more data points - that my results are
not "unusual" or tainted by some other influence I've forgotten
to account for (indeed, this is why you would NEVER take a
single data point only...that's "just not statistics", so to
speak...you need at least _three_ sets of points to overcome the
"degrees of freedom" argument: That is, if you're looking for a
"correlation" and you only take two points then you will
_ALWAYS_ find a "correlation"...why? Because, of course, two
points can _ALWAYS_ make a "line" or "linear relationship"...you
need _at least_ three sets of points in order to prove that a
linear relationship really _IS_ a linear relationship...four
points to prove a simple (quadratic) curved relationship...and
so forth...although, the more points the better...but these are
_minimums_ below which false conclusions can be arrived at by
legitimate process...and, in fact, one typically actually
_excludes_ these "degrees of freedom" points from analysis and
they get deduced away because, by definition, they are not
contributing to the conclusion, even when you have multiple data
points)...

Not that this is the best example because I was being _highly_
"unscientific"...this was not really intended as "proof" of
anything...but just to "get a feel" of which is the method that
has the least "call overhead" (on the presumption that the
fastest is the one with the least "call overhead" and is the
most direct route...did I prove this presumption? Nope...so,
indeed, if anyone feels the presumption is wrong, devise a
test - needn't be highly accurate or anything - which shows the
presumption to be misplaced)...but I do know enough about
statistics to do a reasonable job...

ALTHOUGH, I'd never call this particular test "statistical" in a
month of Sundays...it wasn't meant to be "proof" or to give some
great insight...a very simple "rough test" to give a basic
"rough indication" of which has the _least_ "call overhead" (and
rather than avoid the "call overhead" as you propose, _THAT_ was
exactly what I was trying to determine ;)...

> My plea is that you optimize where it matters. A "call write"
or "call
> time" will be a lot more readable than loading up a constant
in eax and
> int 80h, unless you comment stuff vigorously. Not to mention
that it
> will be a heck lot easier to port (oops, I said a no-no word
;)) your
> sources to other *u*x'es. You don't necessarily have to link
with libc,
> you could write your own tiny wrapper library for LuxAsm.
Doesn't mean
> you have to put parameters on the stack, you can keep them in
registers
> - just "call write" rather than "int 80h".

And you think this is the only way to do it, huh? Been hanging
around C compilers far too long...need to be reminded about
assembly language, I think...

What would be the problem about "readability" and "portability"
with:

------------- 8< ----------------

sys_exit 0

------------- >8 ----------------

Seems "readable" enough, eh? And the "portabilty" is handled
implicitly too by this _MACRO_...

(Pseudo-code syntax to attempt to be "readable" to everyone;
Macro systems are where things tend to get greatly different
between assemblers, after all :)
------------- 8< ----------------

#if (OS == Linux)

    #macro sys_exit(ExitCode)

        mov eax, 1
        mov ebx, ExitCode
        int 80h

    #endmacro

#else

    #macro sys_exit(ExitCode)

        push ExitCode
        call _exit
        add esp, 4

    #endmacro

#endif

------------- >8 ----------------

This covers "readable" and "portable" without forcing the need
for using the C-level functions and getting that 6.25%
penalty...

Yes, with C (the language, not the developer), the only real
available means of "indirection" tends to be the procedure call
only because it has such a, well, crap preprocessor...but ASM is
a touch more versatile and clever...indeed, one of ASM's great
strengths is that most assemblers typically come with some of
the best macro / preprocessor facilities that there are...

> Also, a size notice... I assume syscall number is stored in
eax - "mov
> eax, BLAH" followed by "int 80h" is 7 bytes, eip-relative call
is 5
> bytes. Solve the equation "5x + 7 < 7x", and you get something
like
> (rounded up), "x > 4" (sorry if my math sucks, it's late.) So,
if you
> call a given syscall more than 4 times, doing a "call write"
that sets
> up eax and does int80 will be shorter. Of course things change
if only
> AL has to be loaded ;)

And, in the opposite direction, the C call requires a "PUSH" for
each parameter and some stack clean-up afterward to clear those
away (C calling convention)...while the "INT 80h" only requires
a "MOV register, BLAH" for each parameter...

So, you can't really ignore the parameters in your calculations
reasonably, because of the "C calling convention" adding on the
"stack clean-up" overhead after making the call too (is there
any syscall that doesn't take a parameter at all? Must finish
off compiling that list, indeed...but, indeed, the vast majority
do, if not all, that this "overhead" is always (or mostly
always) there so you really _must_ reasonably factor it into
your calculations too :)...

Hence, add on some "add esp, XX" for the C call (although, this
presents a problem for calculations in that you might use "POP
DummyRegister" to clean up the stack when there's only one
parameter to remove...but would need to do something more
substantial for many parameters like "add esp, xx" :)...

Also, it's a touch more complicated than that..."INT 80h" is
_immediately useable_ without any "linking" that nothing in
addition needs to be added...the C calls, on the other hand,
require some form of linking...and then issues about static
linking, shared libraries, entries in headers and so forth have
to also been thrown into the mix too (and further issues again
that though shared libraries can help avoid such problems,
there's also the possibility of "missing shared libraries" and
other "DLL hell" things to consider :)...

Anyway, this is missing the point somewhat...

Whatever the LuxAsm developers use to develop LuxAsm, this is
NOT the same thing as what the _users_ will use whilst using
LuxAsm...after all, NASM is written in C but it doesn't force
you to write C code while using it, does it? These things are,
of course, _separate_ issues...so, LuxAsm may itself use "INT
80h" internally but this doesn't in any way mean that your Linux
/ X applications need to do the same...it's an assembler, so
type: "push 0; call exit" and be merry!!! There might be those
"macros" available in an include file somewhere...but no
compulsion to include it and force you to use it...hey, we're
not Rene, you know!!

_FREEDOM TO CHOICE_ is a very important issue here...and, note,
it works both ways: Someone who _DOESN'T_ want "portability"
should be just as equally catered for as those who _DO_....in
other words, C calls will NOT be excluded in any way...but
NEITHER will "INT 80h" calls too...support will exist for _BOTH_
and then users _CHOOSE_, according to their _application needs_
(not just "random general preference" ;), which is
correct...indeed, how many times do I have to say this? The
_DEVELOPER_ must _CHOOSE_ and have this responsibility
solely...it should not and will not be "usurped" to inflate the
egoes of the LuxAsm assemblers that "we know best", better than
our "lowly users" (an attitude you might find from HLLs, Rene
and so forth but you won't find it here ;)...NO-ONE else -
however high their "ivory tower" - is actually qualified to make
the choice...in the end, it's the _coal miner_ who understands
better than anyone what the best tools to use at the coalface
are...

There will be the "freedom to choose"...well, in so far as, of
course, you have to account for the fact that things take time
and effort...so, yeah, it might be the case that only, say, Xlib
support is catered for to begin with and you have to wait a
little longer for the "Qt" choice to become available...and,
also, yeah, if there's simply "no demand" from anyone for
something then, again, for practical reasons, the support may
not appear until someone nags for it ("supply and demand")...but
there won't be any bizarre "we know better than you do: you MUST
always use this and that's all!!" Rene-style nonsense (or,
indeed, OS-style nonsense, as they are all tending to be
"control freaks" and "nannying" these days and not only Windows,
which is just the worst but not the only one that takes this
_INCORRECT_ attitude)...

> Dunno how bad it is to link in libc shared, anyway. I do have
the
> impression that linux is retarded, but there must be limits to
HOW
> retarded it can be... at least it sports copy-on-write (and
hopefully
> demand-loading, too.)

[ I've not confirmed it first-hand but I've heard more than one
source mention that Linux does have "demand loading"...it
certainly has the ability - more than something like Windows
supports - to get the loader to only actually bother to
dynamically link a call _when_ it's actually made...the first
call, therefore, takes longer than the rest but if your code has
a number of calls which, in practice, aren't actually called
then it doesn't bother to link those up UNLESS they actually get
called...which is a facility that's "less retarded" than
Windows' dynamic link mechanisms...but, then again, hardly the
greatest claim to fame: "less retarded than Windows"...ooh,
that's so difficult to achieve! hehehe ;) ]

> This means that, apart from pagetables and COW'ed
> regions, the libc runtime should be shared with other
processes running
> on the system. Considering linux's nature, there will be a lot
of
> these, so you can be pretty much guaranteed libc will already
be in
> memory.

Yeah, quite right; But we're comparing to "INT 80h" here...no
linking required at all...directly part of Linux itself that's
always present for an application...you can't really compete
with "none"...the best that could be possible is for the C calls
to also manage "none", which is only _equal_ and not
better...meaning the best we can expect along this line of
thinking is that "INT 80h" and the C calls are equal and it
amounts to an arbitrary choice between them...otherwise,
anything the C call has in addition is "overhead" in comparison
to "INT 80h", which provides the syscalls "out of the box" with
no additional linking or programming or anything...

> Localization through plugins... is a bad idea. Localized
software
> becomes pretty huge this way. If you really want localization
(which I
> personally think is a horrible idea, especially for something
as
> 'advanced' as an assembler), it's better to put all your
strings in an
> external (UTF-8) file, and load strings runtime. You can write
your own
> code for this, or use one of the existing projects. I've done
this for
> commercial projects, and it's *so* much easier to manage than
hunting
> through the source for strings.

Agreed; Localisation is best done through isolating the strings
into a separate file instead...a bad example, in this case,
you're right...

> Btw, your windows DirectX fallback example is a bit silly :).
If you
> need DirectX 9 capability, you _need_ it, and no other version
will do.
> If you need something earlier, that's what you're going to get
(from
> your COM request). You can say what you want about COM and
it's
> implementation, but it's one of the better systems for
providing
> nearly-100% backwards support... the idea of "falling back" is
good,
> but consider _where_ you can apply it...

But, no, I disagree here...it's not at all silly (and those who
swallow Microsoft bullcrap about this in this way, lead to worse
inconsiderate applications)...consider a computer game like "the
Sims"...it has mass-market appeal and isn't only for die-hard
gamers...it's a family game (and you could also consider a game
designed specifically for _young_ children too...like, for
instance, a "Pingu" game about the clay animation cartoon
penguin I once saw that had very simple "match up the shapes"
and "Pingu tennis" games to play :)...if hardware acceleration
is available then we want to take advantage of it to improve
performance...BUT we want it to be able to "fallback" onto
_software_ (using GDI, for example...won't be as good or smooth
but it will still work :) if it cannot be discovered _without_
causing any user visible fuss whatsoever...it's NOT acceptable
for "Pingu tennis", a game for young children, to flash up a
"please install DirectX 9" dialogue box...failing to appreciate
this kind of thing is failing to appreciate your audience's
particular needs...

Indeed, you know what Michael Abrash has been spending his time
doing lately? Exactly creating "fallback" _software_ DirectX
emulation to still provide acceptable 3D performance where
hardware acceleration is either not present or, indeed, not
understood by the user properly (in a survey, which is why I
mentioned "the Sims", it was discovered that _60%_ of users were
running it in the default "software" mode simply because they
_didn't comprehend_ how to set it up otherwise or even that they
needed to do so..."clueless newbies"? Yes, but they are the
_customers_ regardless...if they are clueless then
"cluelessness" must be accounted for)...

If what you're saying is correct - just because Microsoft
recommend it (the same people who will no doubt release Longhorn
with a "requires seven Cray supercomputers with 9 billion
terabytes RAM each" minimum requirements badge because, ooh,
they've added "Clippy" into the corner ;) - then Abrash has been
wasting his time completely...and he'll make no money whatsoever
selling his "fallback" software emulation...wanna make a bet on
what will _really_ happen? There's "theory" and then there's
_practice_...in the end, only _practice_ counts, as "theory" is
merely (an often inaccurate) "model" of practice...but practice
overrides it all, _whatever_ some Microsoft technician quotes as
the "theory of COM"...

Do what you're doing and 60% of your users (from actual user
surveys there) will be getting unacceptable performance and
might likely throw away your product because it's _unuseable_ at
such a reduced speed...especially true of games...if Lara Croft
doesn't jump _exactly_ when you say then, simply, she falls down
the big pit and dies...if this happens three or four times in a
row - when the player _KNOWS_ (and is quite correct, in fact)
that they _DID_ push the joypad at the right moment - the player
throws away the CD and considers it "a con"...possibly never
buying a game from the same manufacturers again because "they
only make sucky games that don't work!!"...many amateur games
authors might think that "cool graphics" is the most important
bit...NOPE, the _reactions_ and "feel" of the input system is
far above _ANYTHING ELSE_ in the entire game...the _enjoyment_
rests on these kinds of things..._THAT_ is the actual "game", so
to speak...the graphics and sound are merely "embellishments" to
decorate the game experience to further that enjoyment...if your
"input system" is wrong and the reactions are all "out of synch"
then there is NOTHING you can do in the graphics, sound, AI or
any other department to correct this...your game will suck,
people will hate playing it: you've just lost your
customers...but, increasingly, many games are _falling over_ on
these most important things because they are NOT accounting for
_people_ but only thinking about "technical" issues...

> >And, yes, I'm being sarcastic about the 90+% stuff to a
> >degree...after all, for all this fuss about "CPU
portability",
> >how many _ACTUAL_ target processors and OSes are there in
> >reality?
>
> If you care about desktop machines at home, it's like "x86 +
windows".
> If you're doing commercial stuff, you shouldn't really care
about
> anything else, unless you're writing niche software - since
"x86 +
> windows" is almost the only market. If you start writing more
"funky"
> stuff, or target servers or embedded devices, there's suddenly
so many
> OS'es and CPU's that you might understand why portable code is
a good
> idea ;). And of course there's the issue of the _stupid_ push
for
> "64bit PC's for everybody!"...

Well, no...in the sense that the actual _numbers_ of OSes and
CPUs doesn't alter at all simply because you've moved from "x86
Windows" to something else...and whether an application _NEEDS_
to be "portable" is not effected by the mere existence of other
OSes and CPUs...

I comprehend that someone moving from "x86 + Windows" to
suddenly discover the wealth of _other possibilities_ that they
had no idea about is a "culture shock"...but I've seen and used
plenty of different systems that the "novel gimmick" doesn't
effect me anymore...

Indeed, it's a touch ironic that you consider the "push" for
"64-bit PCs for everybody" to be "stupid", just because it's now
a possibility...when - *ahem* - what are you really doing here
but also "pushing" portability simply because it can be done?

Yes, Sun Sparcs have cool keyboards...or cross-compiling to
vxWorks on an embedded system has interesting things to
learn...it's all great stuff...and it _IS_ interesting stuff
because I've enjoyed working with all manner of systems...but
the "gimmick" wears off...I'm just not going to be "portable" to
a Sun Sparc simply because I can...I'm going to do so when
there's a _REASON_ and direct _BENEFIT_ for doing so...

I _KNOW_ it's not the popular opinion or the thing that sounds
like "fun"...but I maintain - because it's true - that
"portability" is merely a _MECHANISM_ and it's a _HIGHER-LEVEL_
consideration...something to be decided on an _application by
application_ basis...

Indeed, it's stupid to "push" something just because "it's
possible"...this doesn't mean it's right, though...

In fact, let's _really_ look at this...what is usually meant by
"portability" is "source level compatibility" that an
application can enjoy "write once, re-compile, run
anywhere"...and here comes the blasphemy: I just don't care...

If "write once" means bloat and reduced performance (and it
does)...if "write once" means _crippling_ application software
(and it does)...if "write once" means the automatic use of
_redundent_ mechanisms when they serve _no purpose_ (and, often,
it does)...

Then, quite frankly, you can stick "write once, run anywhere"
where the Sun don't shine...

Give me your _concrete reason_ for "portability" in _a
particular instance_ and, if it's legitimate, I'll back you to
the hilt and help you acheive that "portability" happily (I
intend to do so with Randy's HLA at some point)...but
"portability" simply because it's possible? Because it'll be
"rather clever" to show that you can do it? Nope, not
interested...there's no good reason for it...

Note that Windows only really give a crap about x86 (they
_tried_ "portable" with NT at first...no-one was
interested...yes, even the _world's richest company_ couldn't
make it fly and gave up on it...whatever "theory" suggests,
_practice_ didn't back it up)...

Linus' original Linux post clearly states that "it's not
portable" because it specifically uses '386 devices like task
switching ("UNIX compatible" means providing a particular API
which behaves in the correct manner..._HOW_ "portable" the
implementation _underneath_ that API is, is completely
immaterial...you can, indeed, actually code the kernel itself in
pure assembly language and make very _specific_ use of the
underlying hardware...and, in fact, doing so has some very
_compelling reasons_ supporting it...it'll be an OS that
performs better, is smaller, manages resources better, etc.)...

And if you _recognise_ "portability" as a _class of mechanisms_,
not a single thing, then you can _select_ the more appropriate
mechanism...because, in fact, you can achieve "portability" by
_separating_ "machine-dependent" from "machine-independent" and
then merely "port" the small "machine-dependent" bit...

For example, writing a UNIX OS mostly in C...BUT the more
"machine specific" parts - like the task switching, protected
mode mechanisms, etc. - are in pure assembly language...then,
simply, just the "machine dependent" parts are _re-written_ from
machine to machine (a small effort)...then a "makefile" is
provided for each different platform that _conditionally_
selects out the right "machine dependent" parts in ASM...

Hence, it is "machine independent" source code, in a manner of
speaking...but still features completely "machine dependent" ASM
coded sections in it...a technique that shouldn't sound
particularly odd to OS coders...using C, you more or less _MUST_
include _some_ kind of assembly language for the "machine
dependent" parts...

In the case here, we're talking x86...this is hardly a "niche
market"...indeed, what I'm suggesting is that it's so NOT
"niche" that it _IS_ worth the cost to simply _code directly_
for it...the loss of "portability" is, in fact, not really any
kind of loss in practice...

I mean, let's look at a few things:

1. x86s are 90+% of all machines...

2. This group "alt.lang.asm" actually is NOT x86 specific...but,
yet, we get around 12 posts a year that don't relate to the x86
(which often tend to be "I must use the MC8xxx microprocessor
for my course...where can I find an x86 emulator for it?", that
you even have to consider how non-x86 even posts like that
really are ;)...everyone launches into discussing the x86 and
only the x86 without even blinking...

3. Linux technically runs on other architectures, true
enough...so, those who aren't running it on an x86, please raise
your hand now...because, indeed, if tens of hands were raised
then we can consider "beyond the x86" with LuxAsm...any hands
raised at all here?

4. From Randy's "the Great Debate":

"On the other hand, Software Engineering Researchers typically
point out that coding represents only about 30% of the software
development effort. Even if your program were written in 100%
pure assembly language, one would expect that it would require
no more than 40% of the original effort to completely port the
code to a new processor (the extra 10% provides some time to
handle bugs introduced by typos, etc.).

Perhaps you're thinking 40% is pretty bad. Keep in mind,
however, that porting C/C++ code doesn't take zero effort;
particularly if you switch operating systems while porting your
code. If you're the careful type, who constantly reviews their
code to ensure it's portable, you're simply paying this price
during initial development rather than during a porting phase
(and there is a cost to carefully writing portable code)."

Hence:

4a. Completely re-writes aren't really as bad as you might
think...remember that _ALGORITHM_ and _STRUCTURE_ from the
original program are often still completely 100% re-useable on
another platform...you can't "cut and paste" the code,
true...but you can logically "cut and paste" the idea...a
word-processor is still a word-processor on a different
platform...that part does NOT change...only the _mnemonics_
you're using for that particular architecture (which introduces
the idea I've been presenting before about starting the coding
in a HLL - this captures the "algorithm" and "structure" parts
of the program in abstract form - but then converting this down
to highly optimised assembly language for this particular
_implementation_...when you want to "port" the machine, you
return to the HLL and, again, translate it down to this
different platform's native mnemonics)...

4b. Writing "portable" code isn't NOT free of cost and
effort...above, Randy _only_ covers the "cost" in terms of
things like re-writing code and "being careful"...I would extend
this by noting that "portability" often costs in _performance_,
_size_, _resource management_, etc., etc....and this _IS_
certainly an important consideration because whereas the other
stuff is about "developer effort" - making development life
easier - when "portability" is literally crossing the boundary
that it is delivering a _WORSE_ product...

Delivering a _worse_ product simply to make development life
easier is where I suggest the line is drawn...

You know, this could be compared to a car manufacturer
delivering a much, much slower car because "it makes building
the engine easier"...or that it gets delivered unpainted,
lacking a windscreen (US: windshield), the guards over the rear
lights are missing, one airbag not even installed, the other not
functioning, some of the dashboard lights don't have bulbs put
in, not all of the nuts and bolts and screws are fully tightened
up, the passenger seat not properly attached, etc., etc....it's
actually a bit of a _deathtrap_, in fact...but, hey: "We've got
the best 'time to market' compared to our rivals!"...yes, that's
because your rivals aren't incompetent cowboys who do a
thoroughly dangerous and unprofessional job, just to rush it
through...

> PS: OpenGL isn't all that portable :). To do anything
interesting
> (well, by these days' standards), you need vendor-specific
extensions.
> To use vendor-specific extensions, you need OS-specific
> "GetProcAddress"-like calls. This leads down a wormy path of a
lot of
> #ifdef's and platform+vendor specific code.

Ah, yes...but by "it MUST be portable!" mentality then you
simply _CRIPPLE_ your product to whatever's the "lowest common
denominator" in order to bow at the altar of
"portability"...well, this is what's done in all other instances
when "portability" is needlessly bowed to...the CPU has MMX: No,
that's not "portable"...the CPU has segmentation: No, that's not
"portable"...the CPU has better addressing modes: No, not
"portable"...

Indeed, you're implicitly grasping my point in making this
comment about OpenGL...the bits that are "portable" are
uninteresting because they must be "decided by committee", take
forever to get agreement, they only agree on the simple "lowest
common denominator" stuff, must "conform" to the "standard",
because one target machine doesn't have such-and-such then all
other machines must _suffer_ its absence to accomodate that
platform, etc., etc....

_THAT_ is the essence of the problem with "portability"..._THIS_
is implicitly the _PRICE_ that is being paid to obtain
it...because everything carries a cost and this is the cost of
"portability"...

Sometimes, you need "portability" for a specific reason...it's
part of the application's requirements that it has some
"portability"...this is understood and that application will
simply have to pay the price...BUT it is absurd to have all this
software _crippling_ itself needlessly when there _isn't_ any
particular concrete reason to be "portable", other than often
"well, everyone else seems to be doing it" or "well, it would be
kind of 'nice', don't you think?"...

> PPS: "C is portable" :). Apart from the petty little things
that a lot
> of people write, a lot of code (at least in the term of "what
carries
> the workload") will be happening in algorithmic stuff, that
isn't tied
> to CPU or OS.

This cannot really be stated generically...whether an
application is tied heavily or not to CPU or OS completely
depends on what the application is and what it needs to do and
what the capabilities of the CPU and OS are...

But, yes, for something "typical" like a "database" or whatever,
I'd second what you say here, no problem...

> It's no big task writing this code so that it will
> compile out-of-the-box on little/big-endian 32-bit machines or
64bit
> machines (16-bit compatibility requires a lot, but I hope I'll
never
> have to code for such a limited platform.)

[ "16-bit compatibility requires a lot"?!? You talk about
"portability" on the one hand...but, on the other hand, this
comment only makes sense presuming we mean _x86_ 16-bit with its
horrible, horrible "real mode addressing", "memory models" and
"segmentation" nonsense..._OTHER_ 16-bit architectures, though,
tend to simply be a case of smaller registers and fewer
instructions and that's about it...ah, is this the reason behind
the blind devotion to "portability"? Still a "big deal" for you?
;) ]

> Of course things get messy
> once you need to use advanced features like multithreading or
GUIs, but
> if you plan ahead and don't write "API code", this isn't too
bad either
> (though you may have to live with a crappy-looking UI and
sloppy code,
> wxWindows or whatever.)

Again, you're implicitly confirming the basic point: "have to
live with crappy-looking UI and sloppy code"...there is a _COST_
to "portability"...

> PPPS: "old man with a pipe" wouldn't happen to look something
like
> http://www.virtualbrum.co.uk/tolkien/tolkien-jrr.jpg ?

Ummm, might be...I have no idea...but, knowing that it was
present in the Atari ST character set (four characters you put
together to make the face...an odd character set with strange
additions like this face of a "man with pipe" and the Atari logo
;), I'm set to track down who the face actually is, using
Google:

"In the end, I was reduced to discovering odd facts about the
ST. For example, did you know that although the ST character set
conforms fairly closely to the extended ASCII used on the IBM
PC, it also includes the characters for the Atari Logo, the
entire Hebrew alphabet, and a picture of a man smoking a pipe?
Some people say that the picture of the man looks like Jack
Tramiel himself, smoking a cigar, but I think it looks more like
Hugh Hefner."

Who is the "man with a pipe"?!? And what is he doing on Linux
screen savers?!? There is something mysterious going on...I will
investigate further and report back on the discoveries ;)...

> PPPPS: you write long posts ;)

Correct...

Beth :)

• Previous message: snpphakel: "Re: understanding speed"
• In reply to: f0dder: "Re: LuxAsm questions"
• Next in thread: f0dder: "Re: LuxAsm questions"
• Reply: f0dder: "Re: LuxAsm questions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]