Invisible wrote:
>  From what I've seen, only games programmers go to the extremes of using 
> obscure and elaborate low-level hackery to squeeze every last 
> femtosecond of performance out of the

... desktop ...

 > machine.


FTFY.

I take it you've never seen a program written for a cell phone, a set-top 
box, or an MP3 player?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I take it you've never seen a program written for a cell phone, a set-top 
> box, or an MP3 player?

  Does the iPhone count as one of those?-)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Still, C is a language where, if you so desire, you can make your code 
> depend on the exact size of a struct, the endianness of machine words, 
> and all kinds of other things to make your code extra fragile. I suppose 
> some people would consider this a "feature"...

  Well, sometimes it is useful to be able to poke at memory directly.
For example, changing the sign of a floating point value is much faster
by flipping that one bit at the end of it than doing it with the FPU.
(Of course after this little trick your program will assume IEEE floating
point numbers. But for many purposes that suffices.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> How does it handle uninitialized variables? Data flow analysis?

  At least gcc gives "warning: 'x' is used uninitialized in this function"
when it sees for sure that this is so, and "warning: 'x' might be used
uninitialized in this function" when it can't be sure but it looks like that.

> That, or accessing memory that has already been freed.

  Hasn't happened to me in, like, a decade.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> (Notice that guy who said he couldn't just add a new integer field to
>> a data structure because it would break a few thousand other
>> functions? Does that sound like good abstraction you to?)
> 
> I think that was a few thousand callback functions. I.e., when an event
> happened, it called you with "process_your_event(int1, int2, voidp)" and
> you'd have to recode all those headers.
> 
> (Honestly, I think that would be rather easy, myself.)
> 

It looked like the problem was that the voidp was being free()ed in the
event handler, and the data they wanted to pass into the event handler
was something that couldn't/shouldn't be sent to free(). Maybe copying
that data out to a malloc block would have taken too much time, since it
was for controller inputs.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I take it you've never seen a program written for a cell phone, a set-top 
>> box, or an MP3 player?
> 
>   Does the iPhone count as one of those?-)

If it's part of operating the phone, sure. If it's an add-on game or 
something, probably less so. When you're trying to cut battery usage so you 
turn off the receiver half-way thru getting a packet because you can tell 
from the first half that you're not interested in the second half, that's 
squeezing out performance.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

Warp wrote:
>   Hasn't happened to me in, like, a decade.

Me neither. It doesn't mean I like spending the time ensuring it doesn't 
happen. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:4a8dd657$1@news.povray.org...

> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.

If you think programmers are bad:

http://www.slipperybrick.com/2007/09/airline-seatbelt-engine-straps/

(even if that's not genuine, I've seen enough similar "engineering" hacks).

Post a reply to this message

Invisible schrieb:
> Safe languages don't permit race conditions in the first place.

You're far off from reality there.

Any language that can access a file allows you to program a race 
condition. All you need to do is write two programs to access the same 
file intermittently in a suitable manner.

Any language that can /not/ access a file is useless in practice.

Thus, if safe languages don't permit race conditions in the first place, 
then it follows that safe languages must be useless in practice.

(Some other OS resources will probably qualify as building blocks for a 
race condition generator, too; in this sense, file access is only given 
an example.)

Post a reply to this message

Invisible schrieb:
>>> I especially like the claims of "every time we added debug code, the 
>>> bug went away". Surely it is impossible to work under such conditions...
>>
>> Well, I tell you that's pure reality.
> 
>> Yeah, it's kind of fun developing software for devices where 
>> occasionally the only way to get any helpful debug information out of 
>> the thing is by switching an LED on or off, and errors might just as 
>> well be hardware-related.
> 
> Wouldn't this make it scientifically impossible to deliver a working 
> product?

I'm not sure what you mean by this.

If you're saying, "wouldn't this make it impossible to prove that the 
product is working properly", then yes: Such a proof is impossible for 
virtually /every/ real-life product. Welcome to real-world software (and 
hardware) development.

If you're saying, "if you can't get any debug information out of the 
device except for an LED, how can the product be of use anyway?", then 
you're missing the fact that there might be other interfaces to the 
outside world, which just happen to be unavailable for debugging 
information (e.g. they're not initialized yet when the error occurs, or 
the interface protocol provides no means to introduce any "side channel").

Post a reply to this message