Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12312 > unrolled thread

Looking for experienced C/C++ / ASM programmer

Back to article view | Back to comp.lang.c

Contents

  Looking for experienced C/C++ / ASM programmer "a.owens@novartisoft.com" <a.owens@novartisoft.com> - 2011-10-30 19:47 -0700
    Re: Looking for experienced C/C++ / ASM programmer jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 07:05 -0700
      Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-10-31 07:38 -0700
        Re: Looking for experienced C/C++ / ASM programmer jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 08:51 -0700
          Re: Looking for experienced C/C++ / ASM programmer "BartC" <bc@freeuk.com> - 2011-10-31 16:39 +0000
            Re: Looking for experienced C/C++ / ASM programmer James Kuyper <jameskuyper@verizon.net> - 2011-10-31 12:58 -0400
              Re: Looking for experienced C/C++ / ASM programmer Ark <akhasin@macroexpressions.com> - 2011-11-04 04:51 -0400
            Re: Looking for experienced C/C++ / ASM programmer Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-10-31 10:28 -0700
            Re: Looking for experienced C/C++ / ASM programmer Frederick Williams <freddywilliams@btinternet.com> - 2011-10-31 17:55 +0000
              Re: Looking for experienced C/C++ / ASM programmer Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-01 06:29 -0700
                Re: Looking for experienced C/C++ / ASM programmer jacob navia <jacob@spamsink.net> - 2011-11-01 14:49 +0100
                  Re: Looking for experienced C/C++ / ASM programmer "BartC" <bc@freeuk.com> - 2011-11-01 14:23 +0000
                  Re: Looking for experienced C/C++ / ASM programmer Ian Collins <ian-news@hotmail.com> - 2011-11-02 07:41 +1300
                  Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-01 15:43 -0700
                  Re: Looking for experienced C/C++ / ASM programmer gwowen <gwowen@gmail.com> - 2011-11-04 07:07 -0700
                    Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-04 08:30 -0700
                      Re: Looking for experienced C/C++ / ASM programmer gwowen <gwowen@gmail.com> - 2011-11-04 09:13 -0700
                        Re: Looking for experienced C/C++ / ASM programmer "BartC" <bc@freeuk.com> - 2011-11-06 21:50 +0000
                      Re: Looking for experienced C/C++ / ASM programmer Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 16:37 +0000
                      Re: Looking for experienced C/C++ / ASM programmer Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 13:01 -0500
                        Re: Looking for experienced C/C++ / ASM programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 11:27 -0700
                        Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-04 15:36 -0700
                          Re: Looking for experienced C/C++ / ASM programmer Ian Collins <ian-news@hotmail.com> - 2011-11-05 11:46 +1300
                            Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-04 16:31 -0700
                              Re: Looking for experienced C/C++ / ASM programmer Ian Collins <ian-news@hotmail.com> - 2011-11-05 12:52 +1300
                                Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-04 17:21 -0700
                                  Re: Looking for experienced C/C++ / ASM programmer Ian Collins <ian-news@hotmail.com> - 2011-11-05 13:55 +1300
                                    Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-04 23:23 -0700
                                    Re: Looking for experienced C/C++ / ASM programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-05 04:21 -0700
                                      Re: Looking for experienced C/C++ / ASM programmer Seebs <usenet-nospam@seebs.net> - 2011-11-06 07:40 +0000
                                        Re: Looking for experienced C/C++ / ASM programmer "io_x" <a@b.c.invalid> - 2011-11-06 09:35 +0100
                                        Re: Looking for experienced C/C++ / ASM programmer Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 16:34 +0000
                                        Re: Looking for experienced C/C++ / ASM programmer BGB <cr88192@hotmail.com> - 2011-11-06 12:47 -0700
                                Re: Looking for experienced C/C++ / ASM programmer Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 00:31 +0000
                  Re: Looking for experienced C/C++ / ASM programmer Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-05 02:29 -0700
            Re: Looking for experienced C/C++ / ASM programmer Patrick Scheible <kkt@zipcon.net> - 2011-10-31 13:03 -0700
            Re: Looking for experienced C/C++ / ASM programmer jgk@panix.com (Joe keane) - 2011-11-04 13:12 +0000

Page 2 of 2 — ← Prev page 1 [2]

#12708

On Nov 4, 8:01 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Fri, 04 Nov 2011 08:30:03 -0700, BGB <cr88...@hotmail.com> wrote:
>
> Smartphone shipments started exceeding PC shipments last year.  And
> those are all programmable (and does not include feature phones or
> tablets).
>
> For the vast majority of users, PC effectively aren't programmable
> either - almost all software run on 95% of PCs is written by a "few"
> people who then run off "millions" of units.
>
Currently I'm running a version of Windows. Open are two "folders", an
Open Office document with my novel in it, a copy of wordpad showing
some C source, a copy of a source editor called Crimson Editor, a
command prompt window which I use for running tcc (tiny C compiler),
Adobe Viewer with a scientific paper, and, of course, the web browser
I'm typing this into.

So most of these programs are mass market ones, and the ones that
aren't are to do with programming.

That's one reason we're seeing a shift from PCs to less flexible (in
software terms) but more portable and easier to use devices. Most
people want to run a fairly limited set of programs. The exception is
games, but even here, games are moving to the internet.

--
Download free games:
http://www.malcolmmclean.site11.com/www

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

#12735

On 11/4/2011 11:01 AM, Robert Wessel wrote:
> On Fri, 04 Nov 2011 08:30:03 -0700, BGB<cr88192@hotmail.com>  wrote:
>
>> people say that "smartphones/tablets/... as future", however this seems
>> unlikely. far more likely, they will be used alongside desktops and
>> laptops and like, and after a few years people will wonder why their
>> sales drop so much: "oh yeah... market saturation...".
>
>
> Smartphone shipments started exceeding PC shipments last year.  And
> those are all programmable (and does not include feature phones or
> tablets).
>

but, this is because the market has not yet saturated.

PC sales are lower because the market is fairly saturated:
say, one buys a PC in 2007, and it still works fairly well now, so why 
buy a new one?... likewise, if one has a laptop from 2003, and it still 
works...

whereas not everyone has a smartphone or tablet, so people are still 
making sales.
once nearly everyone who wants a smartphone or tablet has one, then 
sales will likely drop off significantly, with most new sales either 
being to get new features/upgrades, or to replace lost/damaged units.


the issue is that current sales are a poor indicator of total units in-use.

so, the question is what the sales will look like once market saturation 
is reached.


>
>> for most small embedded devices, the number of units is misleading, as
>> most are non-programmable, so maybe a few people produce the original
>> software for a given device, but they run off millions of units. doesn't
>> mean that this constitutes a larger amount of total work (by
>> programmers), only that a large number of units have been produced.
>
>
> For the vast majority of users, PC effectively aren't programmable
> either - almost all software run on 95% of PCs is written by a "few"
> people who then run off "millions" of units.

but, there are lots more programmers on the PC, like just how many 
people are involved in the creation of typical desktop software (such as 
an OS, web-browser, of office suite).


whereas, say, with an alarm-clock (or watch, or microwave oven, ...), 
pretty much the entire system (software-wise) is implemented by a single 
person. many other units would be things like set-top boxes,  broadband 
routers, DSL or cable modems, ... again, most of which are largely 
non-programmable.


with a system like Android, much of the "actual work" was likely done by 
people who were originally targeting the PC (say, everyone involved in 
writing the Linux kernel).

it is not clear if at this point the entire combined code-base of 
dedicated Android software likely exceeds that which has gone into the 
Linux kernel (somewhere around 40 Mloc last I checked).


also, given one can just wander around, and encounter people IRL who 
write software (most often them being for C# or VB.NET or similar, 
generally doing something involving an SQL-Server backend), indicates 
that programmers (at least in some form) are not *that* rare.

I have thus far IRL only encountered a single person who was writing 
apps for a mobile target, and this was for iOS (the person in question 
being primarily an Objective-C developer). the person in question also 
wrote software for OS/X.


or such...

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

#12738

On 11/ 5/11 11:36 AM, BGB wrote:
> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>
>> For the vast majority of users, PC effectively aren't programmable
>> either - almost all software run on 95% of PCs is written by a "few"
>> people who then run off "millions" of units.
>
> but, there are lots more programmers on the PC, like just how many
> people are involved in the creation of typical desktop software (such as
> an OS, web-browser, of office suite).

So what minute fraction of 1% of those programmers are writing (or even 
know how to write) in assembler?

-- 
Ian Collins

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

#12741

On 11/4/2011 3:46 PM, Ian Collins wrote:
> On 11/ 5/11 11:36 AM, BGB wrote:
>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>
>>> For the vast majority of users, PC effectively aren't programmable
>>> either - almost all software run on 95% of PCs is written by a "few"
>>> people who then run off "millions" of units.
>>
>> but, there are lots more programmers on the PC, like just how many
>> people are involved in the creation of typical desktop software (such as
>> an OS, web-browser, of office suite).
>
> So what minute fraction of 1% of those programmers are writing (or even
> know how to write) in assembler?
>

who knows exactly?...

but, at least parts of both Linux and FireFox are written in 
assembler... (although the vast majority of this is C, or a mix of C and 
C++ in the case of FF).


parts of my 3D engine and VM stuff are also written in assembler 
(although the vast majority of the code is C).

in terms of raw volume, it is possible that my ASM code is smaller than 
the amount of code I have written in Java and BGBScript...

there is pretty much no pure/standalone ASM in my stuff, as most of what 
is present is either inline assembler (minor), or procedurally-generated 
assembler (more common), much of this being either because:
it is doing something difficult to do in plain C;
because ASM is really fast to "eval" (my assembler can assemble 
10-20MB/s of ASM code, which can be transformed readily into callable 
function pointers);
because it didn't really fit well with using BGBScript for some reason;
...


the Quake3 engine also manually-crafted machine code in a few places 
(generally building machine code from hex-strings).

I guess the question would be to determine just how many people 
in-general use ASM/native-code this was...


or such...

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

#12742

On 11/ 5/11 12:31 PM, BGB wrote:
> On 11/4/2011 3:46 PM, Ian Collins wrote:
>> On 11/ 5/11 11:36 AM, BGB wrote:
>>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>>
>>>> For the vast majority of users, PC effectively aren't programmable
>>>> either - almost all software run on 95% of PCs is written by a "few"
>>>> people who then run off "millions" of units.
>>>
>>> but, there are lots more programmers on the PC, like just how many
>>> people are involved in the creation of typical desktop software (such as
>>> an OS, web-browser, of office suite).
>>
>> So what minute fraction of 1% of those programmers are writing (or even
>> know how to write) in assembler?
>>
>
> who knows exactly?...

So "lots of people" is a small number.

> but, at least parts of both Linux and FireFox are written in
> assembler... (although the vast majority of this is C, or a mix of C and
> C++ in the case of FF).

Very small parts, parts that need to access machine registers.  The only 
x86 bits assembler I've ever had to write are low level scheduling 
primitives.

> the Quake3 engine also manually-crafted machine code in a few places
> (generally building machine code from hex-strings).

Yet another very small niche.

> I guess the question would be to determine just how many people
> in-general use ASM/native-code this was...

Hardly any.

-- 
Ian Collins

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

#12744

On 11/4/2011 4:52 PM, Ian Collins wrote:
> On 11/ 5/11 12:31 PM, BGB wrote:
>> On 11/4/2011 3:46 PM, Ian Collins wrote:
>>> On 11/ 5/11 11:36 AM, BGB wrote:
>>>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>>>
>>>>> For the vast majority of users, PC effectively aren't programmable
>>>>> either - almost all software run on 95% of PCs is written by a "few"
>>>>> people who then run off "millions" of units.
>>>>
>>>> but, there are lots more programmers on the PC, like just how many
>>>> people are involved in the creation of typical desktop software
>>>> (such as
>>>> an OS, web-browser, of office suite).
>>>
>>> So what minute fraction of 1% of those programmers are writing (or even
>>> know how to write) in assembler?
>>>
>>
>> who knows exactly?...
>
> So "lots of people" is a small number.
>

but what is to say it is any smaller than the number of people writing 
ARM assembler?...

most cases, if one is developing on ARM, it is also in C or C++ or similar.


>> but, at least parts of both Linux and FireFox are written in
>> assembler... (although the vast majority of this is C, or a mix of C and
>> C++ in the case of FF).
>
> Very small parts, parts that need to access machine registers. The only
> x86 bits assembler I've ever had to write are low level scheduling
> primitives.
>

most "pure ASM" stuff I did was related to things like bootloaders and 
entry-points for kernels and processes (or "crt0 stubs" or whatever they 
are best called).

also, a few misc things, like code for 128 and 256 bit multiplication 
and division and similar.


most other ASM I have done has been "impure", usually because it is 
either inline assembler, or is related to procedural code generation.

I distinguish between procedural code-generation tasks, and a full 
codegen (such as a JIT or compiler), primarily on the level of scale and 
complexity involved.


>> the Quake3 engine also manually-crafted machine code in a few places
>> (generally building machine code from hex-strings).
>
> Yet another very small niche.
>

yeah...

actually, my strategy was originally partly influenced by the Quake3 
strategy (in the use of command-laden hex-strings), but sort of differed 
in that in my case it was later transformed into an x86 assembler, and 
most later effort was based on producing globs of ASM and feeding them 
through said assembler, rather than via more direct means (most of which 
were generally bulkier and much more effort...).

typically, in this case, one uses "printf()" style calls to produce code 
to be run (in my case generally managed by begin/end pairs...).

in its present form:
void (*fcn)();
...
dyllAsmBegin();
...
dyllAsmPrint("...", ...);
...
fcn=dyllAsmEnd();
...
fcn();


>> I guess the question would be to determine just how many people
>> in-general use ASM/native-code this was...
>
> Hardly any.
>

maybe so.


then again, by a similar notion "hardly anyone" makes use of eval 
either, but it is fairly usedful, when needed, in languages which have it...


or such...

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

#12748

On 11/ 5/11 01:21 PM, BGB wrote:
> On 11/4/2011 4:52 PM, Ian Collins wrote:
>> On 11/ 5/11 12:31 PM, BGB wrote:
>>> On 11/4/2011 3:46 PM, Ian Collins wrote:
>>>> On 11/ 5/11 11:36 AM, BGB wrote:
>>>>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>>>>
>>>>>> For the vast majority of users, PC effectively aren't programmable
>>>>>> either - almost all software run on 95% of PCs is written by a "few"
>>>>>> people who then run off "millions" of units.
>>>>>
>>>>> but, there are lots more programmers on the PC, like just how many
>>>>> people are involved in the creation of typical desktop software
>>>>> (such as
>>>>> an OS, web-browser, of office suite).
>>>>
>>>> So what minute fraction of 1% of those programmers are writing (or even
>>>> know how to write) in assembler?
>>>>
>>>
>>> who knows exactly?...
>>
>> So "lots of people" is a small number.
>>
>
> but what is to say it is any smaller than the number of people writing
> ARM assembler?...

Who knows?  But I'd wager there are more people writing ARM assembler 
simply because it's popular in embedded platforms and many of these run 
OS free.  But even there, the number will be getting smaller.  I'm 
designing an ARM based module at the moment and I can all but guarantee 
I won't have to write any assembler.

> most cases, if one is developing on ARM, it is also in C or C++ or similar.

Quite. In a hosted environment, the choice of language is broader still.

>>> but, at least parts of both Linux and FireFox are written in
>>> assembler... (although the vast majority of this is C, or a mix of C and
>>> C++ in the case of FF).
>>
>> Very small parts, parts that need to access machine registers. The only
>> x86 bits assembler I've ever had to write are low level scheduling
>> primitives.
>
> most "pure ASM" stuff I did was related to things like bootloaders and
> entry-points for kernels and processes (or "crt0 stubs" or whatever they
> are best called).

As I said, very small parts.  Not may of us have to dabble at that level.

>>> I guess the question would be to determine just how many people
>>> in-general use ASM/native-code this was...
>>
>> Hardly any.
>
> maybe so.
>
> then again, by a similar notion "hardly anyone" makes use of eval
> either, but it is fairly usedful, when needed, in languages which have it...

True, but at least eval uses the same language!

-- 
Ian Collins

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

#12764

On 11/4/2011 5:55 PM, Ian Collins wrote:
> On 11/ 5/11 01:21 PM, BGB wrote:
>> On 11/4/2011 4:52 PM, Ian Collins wrote:
>>> On 11/ 5/11 12:31 PM, BGB wrote:
>>>> On 11/4/2011 3:46 PM, Ian Collins wrote:
>>>>> On 11/ 5/11 11:36 AM, BGB wrote:
>>>>>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>>>>>
>>>>>>> For the vast majority of users, PC effectively aren't programmable
>>>>>>> either - almost all software run on 95% of PCs is written by a "few"
>>>>>>> people who then run off "millions" of units.
>>>>>>
>>>>>> but, there are lots more programmers on the PC, like just how many
>>>>>> people are involved in the creation of typical desktop software
>>>>>> (such as
>>>>>> an OS, web-browser, of office suite).
>>>>>
>>>>> So what minute fraction of 1% of those programmers are writing (or
>>>>> even
>>>>> know how to write) in assembler?
>>>>>
>>>>
>>>> who knows exactly?...
>>>
>>> So "lots of people" is a small number.
>>>
>>
>> but what is to say it is any smaller than the number of people writing
>> ARM assembler?...
>
> Who knows? But I'd wager there are more people writing ARM assembler
> simply because it's popular in embedded platforms and many of these run
> OS free. But even there, the number will be getting smaller. I'm
> designing an ARM based module at the moment and I can all but guarantee
> I won't have to write any assembler.
>

fair enough...


>> most cases, if one is developing on ARM, it is also in C or C++ or
>> similar.
>
> Quite. In a hosted environment, the choice of language is broader still.
>

yep.

C has a merit for use in embedded systems:
no real need for an OS or a VM framework.


>>>> but, at least parts of both Linux and FireFox are written in
>>>> assembler... (although the vast majority of this is C, or a mix of C
>>>> and
>>>> C++ in the case of FF).
>>>
>>> Very small parts, parts that need to access machine registers. The only
>>> x86 bits assembler I've ever had to write are low level scheduling
>>> primitives.
>>
>> most "pure ASM" stuff I did was related to things like bootloaders and
>> entry-points for kernels and processes (or "crt0 stubs" or whatever they
>> are best called).
>
> As I said, very small parts. Not may of us have to dabble at that level.
>

well, yes, but writing large volumes of code in plain ASM would "kinda 
suck...".


>>>> I guess the question would be to determine just how many people
>>>> in-general use ASM/native-code this was...
>>>
>>> Hardly any.
>>
>> maybe so.
>>
>> then again, by a similar notion "hardly anyone" makes use of eval
>> either, but it is fairly usedful, when needed, in languages which have
>> it...
>
> True, but at least eval uses the same language!
>

yeah.

sadly, C generally lacks a proper eval.

in my case, I can use the BGBScript eval and generally call it "good 
enough" (the syntax is fairly similar, and the FFI sufficiently 
transparent, that it will often work "about right").

sadly, proper C is not terribly well suited for use in eval (and by the 
time one fudged it enough to be to be better suited for use with eval, 
it wouldn't be particularly C anymore).

my own attempt was slow (WRT compile times), buggy, and not very useable 
for interactive use. likewise, having to include headers, type out 
complete functions, and not having the ability to execute 
statements/expressions at the toplevel, is not ideal for interactive 
entry. (just using ASM was actually a much preferable experience...).


FWIW, many parts of the BGBScript VM themselves depend on the ability to 
print out and execute ASM/native-code.

so, I generally classify it as an "impure interpreter" or "native-code 
enhanced interpreter".

so:
a "pure interpreter" would be one written purely in C (or another HLL);
a compiler or JIT would essentially directly produce native code, and 
then run this (this is what my C compiler did);
so, an "impure interpreter" is be primarily an interpreter (main 
control/dispatch logic is written in C), whereas many parts of the 
execution-path may involve dynamically-generated machine code.

nevermind the use of function-pointer based "plumbing-pipe" logic (where 
one short-circuits some logic code by essentially building the logic 
using function-pointers and swapping around functions, in place of 
winding through more general-purpose logic code). in this case, it is 
like "plumbing pipes" in that one piece of logic will set up the pipes, 
and subsequent control flow will "flow" through said pipes (by calling 
through the function pointers). in a few cases I had actually gained 
significant speedups by doing this.


I also have considered the possibility of migrating over to 
threaded-code, but then the definitions start getting fuzzy (is it still 
an interpreter at this point?...).

one possible definition could be:
it is still an interpreter if it retains a traditional 
instruction-dispatch loop (but, would this include the use of a 
trampoline loop?...).

(the design I had considered would no longer have an instruction 
dispatch loop, but would retain the use of a trampoline loop, as my 
interpreters tend to essentially operate in a CPS-like manner).


or such...

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

#12770

On Nov 5, 2:55 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> As I said, very small parts.  Not may of us have to dabble at that level.
>

If you're writing a video game, probably what you'll fund is that you
need a function to normalise vectors for lighting, and that it's
called millions of times and is a bottleneck. So to speed things up
you need to express the normal as three signed chars, then write a
rough and ready way of getting the length, which doesn't involve a
call to square root. So it's a job for assembly. It's only one
function, but it's absolutely vital that you have someone who can
write it.

--
Read my book Basic Algorithms: compression, Fourier transforms, 3D
video games, and much more.
http://www.malcolmmclean.site11.com/www

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

#12803

On 2011-11-05, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> If you're writing a video game, probably what you'll fund is that you
> need a function to normalise vectors for lighting, and that it's
> called millions of times and is a bottleneck. So to speed things up
> you need to express the normal as three signed chars, then write a
> rough and ready way of getting the length, which doesn't involve a
> call to square root. So it's a job for assembly. It's only one
> function, but it's absolutely vital that you have someone who can
> write it.

So far as I can tell, this post was probably accurate sometime in the early
90s, but isn't now.  In particular, stuff like that is very, very, often done
in hardware, so you don't have to do that *at all* -- you merely tell the
hardware that you want some lighting, and whaddya know, there is lighting.

It's also not at all obvious that, even if you did need to write such a
thing, you would consistently find that hand-writing it in assembly was a good
choice.  Even assuming that your video game runs only on x86 processors, like
those used in the Xbox 360 and PS3 -- whoops, those are both PowerPC, I was
thinking of the iPhone and iPad -- whoops, those are both ARM...  You may well
find that you can't beat a compiler on well-written code to begin with.

Back in the 90s, we had people claiming that assembly was necessary for
performance-critical stuff in this group.  At least one of them, admittedly
something of a twit, produced an example of a function which "needed" to be
in assembly for speed.  His assembly code for it was, on real hardware,
noticably slower than at least one reasonably straightforward C
implementation.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#12808

"Seebs" <usenet-nospam@seebs.net> ha scritto nel messaggio
news:slrnjbcfmk.2q8f.usenet-nospam@guild.seebs.net...
> On 2011-11-05, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>> If you're writing a video game, probably what you'll fund is that you
>> need a function to normalise vectors for lighting, and that it's
>> called millions of times and is a bottleneck. So to speed things up
>> you need to express the normal as three signed chars, then write a
>> rough and ready way of getting the length, which doesn't involve a
>> call to square root. So it's a job for assembly. It's only one
>> function, but it's absolutely vital that you have someone who can
>> write it.
>
> So far as I can tell, this post was probably accurate sometime in the early
> 90s, but isn't now.  In particular, stuff like that is very, very, often done
> in hardware, so you don't have to do that *at all* -- you merely tell the
> hardware that you want some lighting, and whaddya know, there is lighting.
>
> It's also not at all obvious that, even if you did need to write such a
> thing, you would consistently find that hand-writing it in assembly was a good
> choice.  Even assuming that your video game runs only on x86 processors, like
> those used in the Xbox 360 and PS3 -- whoops, those are both PowerPC, I was
> thinking of the iPhone and iPad -- whoops, those are both ARM...  You may well
> find that you can't beat a compiler on well-written code to begin with.

the program heaven it is to have 8 general porpose registers of 32 bits
all instructions for jump trhu the code in base to the unsigned math
=, ^=, |=, &=, =<<, =>>, +=, -=, mul[*=], div[/=], cmp[<>] all on unsigned math
2 operand for instruction
call , ret
a stack for save restore etc the instructions push and pop on it
and some memory for save the program
and one right assembler to show good all that
and assign significance names to some well defined part of  memory

> Back in the 90s, we had people claiming that assembly was necessary for
> performance-critical stuff in this group.  At least one of them, admittedly
> something of a twit, produced an example of a function which "needed" to be
> in assembly for speed.  His assembly code for it was, on real hardware,
> noticably slower than at least one reasonably straightforward C
> implementation.

when it is need: i like to be slower

> -s
> -- 
> Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
> http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
> http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my opinions.

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

#12815

On 2011-11-06, Seebs <usenet-nospam@seebs.net> wrote:
> Back in the 90s, we had people claiming that assembly was necessary for
> performance-critical stuff in this group.  At least one of them, admittedly
> something of a twit, produced an example of a function which "needed" to be
> in assembly for speed.  His assembly code for it was, on real hardware,
> noticably slower than at least one reasonably straightforward C
> implementation.

I remember many years ago finding a very idiotic book in the library about
assembly language programming (Motorola 68000) on the Apple Mac.

The textbook presented a circle-drawing routine, and bragged about it only
takes a quarter second (don't remember the exact time unit) to draw a big
circle, thanks to being written in assembly language!

I thought, what? On the same machine, the classic MacPaint program draws fat
ellipses at a decent enough frame rate that you can interactively resize the
suckers. Haven't these authors ever used any applications on a Mac?

So I looked at what their routine was doing. It was using the naive algorithm
based on square root instead of Bresenham!

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

#12827

On 11/6/2011 12:40 AM, Seebs wrote:
> On 2011-11-05, Malcolm McLean<malcolm.mclean5@btinternet.com>  wrote:
>> If you're writing a video game, probably what you'll fund is that you
>> need a function to normalise vectors for lighting, and that it's
>> called millions of times and is a bottleneck. So to speed things up
>> you need to express the normal as three signed chars, then write a
>> rough and ready way of getting the length, which doesn't involve a
>> call to square root. So it's a job for assembly. It's only one
>> function, but it's absolutely vital that you have someone who can
>> write it.
>
> So far as I can tell, this post was probably accurate sometime in the early
> 90s, but isn't now.  In particular, stuff like that is very, very, often done
> in hardware, so you don't have to do that *at all* -- you merely tell the
> hardware that you want some lighting, and whaddya know, there is lighting.
>

well, there is a little more than that:
if one wants lighting that doesn't look like crap, then it is needed to 
write pixel shaders / fragment shaders.

granted, these are typically in GLSL or similar.


> It's also not at all obvious that, even if you did need to write such a
> thing, you would consistently find that hand-writing it in assembly was a good
> choice.  Even assuming that your video game runs only on x86 processors, like
> those used in the Xbox 360 and PS3 -- whoops, those are both PowerPC, I was
> thinking of the iPhone and iPad -- whoops, those are both ARM...  You may well
> find that you can't beat a compiler on well-written code to begin with.
>

the option is, of course, to write different ASM versions for pretty 
much any combination of OS and/or CPU one wants to run on.

so, ASM versions for:
Windows and Linux on x86;
Windows on x86-64;
Linux on x86-64;
XBox 360 (PPC);
PS3 (PPC);
iPhone and iPad (ARM);
Android (ARM).

the reason some targets for the same CPU are duplicated, is because 
there are generally ABI differences between the targets (actually, there 
are ABI differences between Windows and Linux on x86, but one can often 
hedge around them).

if one is using an external assembler, then there is an issue that the 
exact syntax will often vary from one assembler to another. likewise for 
inline assembler (which is often compiler-specific).

the result is that often it is better to limit ASM to cases where the 
task can't be effectively accomplished in C, which is usually because it 
involves breaking through the normal language abstractions, and is 
rarely particularly related to performance.


this is also partly why I use my own in-program assembler: I can better 
control the ASM syntax (and most things I use ASM for wouldn't work so 
well with static ASM anyways).

my stuff currently runs on a combination of Windows and Linux on x86, 
x86-64, and ARM (although on ARM many things are disabled as I have not 
yet ported the ASM-generation logic...).

in a few cases, I did make use of fallback pure-C logic (such as 
handling "apply" via a giant procedurally-generated "switch()" block). 
its limitation is that it only deals with certain argument types and 
only currently supports up to 6 arguments or so (and produces a 200kB or 
so object file).


> Back in the 90s, we had people claiming that assembly was necessary for
> performance-critical stuff in this group.  At least one of them, admittedly
> something of a twit, produced an example of a function which "needed" to be
> in assembly for speed.  His assembly code for it was, on real hardware,
> noticably slower than at least one reasonably straightforward C
> implementation.
>

yep.


I guess a question would be if there is any good way to apply an 
arbitrary argument list (not known until runtime) against an arbitrary 
function pointer, without needing a giant switch statement.

likewise goes for some way to produce a function pointer which can:
accept an arbitrary argument list (only known at runtime);
keep track of internal state.

the way I had generally handled this was to generate a thunk which would:
fold the arguments into an on-stack buffer;
keep track of a data-pointer given to it at construction;
call its attached function with the data-pointer and the arguments buffer.

generally, this was used to plug script-language functions into C 
function pointers.

I have not yet come up with any "good" way to do this in pure C, apart 
from generating arrays of dummy functions (and allocating from these), 
and assigned pointers, and figuring out a good/portable way to do 
0-argument varargs (normally, stdarg needs at least 1 fixed argument, 
which is a problem in this case).


also, a number of other tasks roughly along these lines.


ASM is also sort of needed to implement a JIT, as otherwise one has an 
interpreter which will generally run slower than native code, but very 
often this is not a huge issue (where I need performance and where I am 
using my scripting language don't really overlap all that much, so no 
huge issue that it is an interpreter...).


most other things though are plain C though, as (generally) the C 
compiler does a fairly decent job.

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

#12745

On 2011-11-04, Ian Collins <ian-news@hotmail.com> wrote:
> On 11/ 5/11 12:31 PM, BGB wrote:
>> On 11/4/2011 3:46 PM, Ian Collins wrote:
>>> On 11/ 5/11 11:36 AM, BGB wrote:
>>>> On 11/4/2011 11:01 AM, Robert Wessel wrote:
>>>>>
>>>>> For the vast majority of users, PC effectively aren't programmable
>>>>> either - almost all software run on 95% of PCs is written by a "few"
>>>>> people who then run off "millions" of units.
>>>>
>>>> but, there are lots more programmers on the PC, like just how many
>>>> people are involved in the creation of typical desktop software (such as
>>>> an OS, web-browser, of office suite).
>>>
>>> So what minute fraction of 1% of those programmers are writing (or even
>>> know how to write) in assembler?
>>>
>>
>> who knows exactly?...
>
> So "lots of people" is a small number.
>
>> but, at least parts of both Linux and FireFox are written in
>> assembler... (although the vast majority of this is C, or a mix of C and
>> C++ in the case of FF).
>
> Very small parts, parts that need to access machine registers.  The only 
> x86 bits assembler I've ever had to write are low level scheduling 
> primitives.
>
>> the Quake3 engine also manually-crafted machine code in a few places
>> (generally building machine code from hex-strings).
>
> Yet another very small niche.
>
>> I guess the question would be to determine just how many people
>> in-general use ASM/native-code this was...
>
> Hardly any.

Writing in assembly language is something that any competent developer
can be called upon to do, but rarely will be.

There is hardly any need for anyone to be an "assembly language programmer".

However, *debugging* at the machine level is far from uncommon.

Tough bugs in optimized C code cannot all be found without resorting to
examining the program state at the instruction, register and memory level.

I haven't had a job in the past 20 years in which I did not have to get up to
the elbows in the machine language to root cause a few bugs.  The fix didn't
involve writing machine language, but the bug hunt required reading machine
language: knowing the instruction set, register usage, calling convention,
structure of the stack and other info, etc.

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

#12767

On Nov 1, 1:49 pm, jacob navia <ja...@spamsink.net> wrote:
> Le 01/11/11 14:29, Nick Keighley a écrit :
>
> > On Oct 31, 5:55 pm, Frederick Williams<freddywilli...@btinternet.com>
> > wrote:
> >> BartC wrote:
> >>> What do you think the chances are of them wanting pdp-11 or z80 programmers?
>
> >> I have PLAN experience, if that's any help!
>
> > ICL 1900 series.
>
> > How about Myriad User Code?
>
> One of the big problems of old people is that they tend to live
> in the past.
>
> ANY discussion in this group leads to
>
> "And in machine XXX (dead since at least 20 years) bytes were
> 8.75 bits, remember that eh?"
>
> This has nothing with remembering history but everything
> with seeking to revive "old memories of yore".
>
> I have nothing against old people but as I age, I try to
> stay away from old age's pitfalls, in the same way as when I was young
> I tried to avoid young age's pitfalls.

I my defence I didn't start the "thermionic valves! you were lucky we
had to grease t'rachets everymorning at 4am with frozen lard!"

It's still worth remembering the whole world isn't a VAX/Unix/Wintel
machine. At that there might be some surprises in future.

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

#12403

"BartC" <bc@freeuk.com> writes:

> "jgharston" <jgh@arcade.demon.co.uk> wrote in message
> news:ae2417a7-feb6-413b-be40-4080484ff340@g7g2000vbv.googlegroups.com...
>> BGB wrote:
>>> jgharston wrote:
>>> > Which assembler?
>>> and what sort of job?...
>>
>> Too often HR droids think "assembler" means x86 without realising
>> there's dozens of specific assembler.
>>
>> I've programmed in 6502, Z80, 6809, 32016, ARM, PDP-11 as well
>> as x86, but I doubt they'd realise they were also all "assembler"
>> even if you dropped it on them from as great height.
>
> What do you think the chances are of them wanting pdp-11 or z80 programmers?

A programmer who's experienced in sevearl different types of assembly is
probably going to have an easier time learning the Next Big Thing than a
programmer with only one assembly language.

-- Patrick

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

#12674

I learned 6502 when i was a kid (no we didn't have assembler, you just
have to put the codes in a BASIC string), later PDP-11, and then any
assembler language seems the same.

I guees i'm an old fart?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web