>> 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?

>> "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

>> "They take care of internal housekeeping."
>> ...actually...
>
> Program Status Word.

The /registers/ do not take care of anything. The /processor/ does.

>> 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.

>> 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"?

Post a reply to this message