On 4/20/2012 1:38, Invisible wrote:
>>> In other words, yet again, "now you know how this works, you don't
>>> need to actually use it".
>>
>> Right. Except in very limited circumstances when you know how deeply
>> you'll recurse, because there's no guarantee it'll work and no way to
>> check.
>
> ...what?

You have no way of knowing how much stack space you have. Nobody writing 
reliable code wants to recurse for each level of a tree without knowing how 
deep the tree is.

>>> "Registers are a special area of memory built right into the CPU."
>>> Erm...
>>
>> What's questionable about that? Heck, on the Sigma 9, the registers 0
>> thru 15 were actually addressed as memory locations 0 thru 15, to the
>> point where you could store program code in the registers and branch to it.
>
> Nobody designs hardware like that any more. Haven't done for decades. :-P

So? They're still special areas of memory built into the CPU. Just because 
you can't address them using normal addressing modes any more doesn't mean 
they're not memory.

>>> "They take care of internal housekeeping."
>>> ...actually...
>>
>> Program Status Word.
>
> The /registers/ do not take care of anything. The /processor/ does.

Oh come on. :-)  The TLB registers take care of internal housekeeping 
certainly.  As do watchdog timer counters, interrupt mask levels, etc.

>>> So I'm guessing an architecture exists where the instruction pointer
>>> /isn't/ a single register then? :-P
>>
>> Yep. Anything with memory mapping hardware, segment registers, etc.
>
> None of which are relevant in the current day and age, unless you're writing
> an OS. Certainly this technicality has no place in an introductory
> programming text.

You asked. The IP address isn't a single register even on a 8086, and that 
isn't *that* long ago.

>>> Still, it does answer something I've always wondered about: What *is*
>>> the C calling convention?
>>
>> Undefined, generally speaking. Or rather, implementation-specific. And
>> depends on pragmas, sometimes.
>
> So you're telling me that the de facto calling convention that all software
> always uses is "undefined"?

Implementation-specific, yes.  How could you define it in a standard when 
you don't even know what architecture you're compiling for?

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message