Re: Atomic operations in 32 and 64 bit platforms

On Jul 25, 8:29 am, Gil Hamilton <spamt...@xxxxxxxxxx> wrote:
"Rod Pemberton" <spamt...@xxxxxxxxxx> wrote innews:g6bai7$fn9$1@xxxxxxxx:





"Gil Hamilton" <spamt...@xxxxxxxxxx> wrote in message
news:Xns9AE55FAFF2408gilhamiltonhotmailco@xxxxxxxxxxxxxxxx
2) ANSI C, through the use of syntax - specifically ellipsis
'...', allows
a compiler to evaluate functions with fixed parameters in any order
instead of just right-to-left order. (i.e., cdecl in this
situation) (I.e., a compiler can choose the best calling
convention, which are 'C calling convention' or 'cdecl' and
'Pascal' in this situation, from Rahul Dhesi's earlier comments.)

'cdecl' and 'pascal' have nothing to do with order of argument
evaluation.

The problem, as I see it, is with the restricted meaning you and Phil
chose to apply to "evaluated". Perhaps, it's from mathematics or the
C spec.

If you look at the C language grammar, you will see that each of the
arguments passed to a function is considered an 'expression'. The
expression must be 'evaluated' in order to determine the actual argument
value to be passed to the called function at run-time. The expression
evaluation can involve (among other things) loading values from memory,
performing arithmetic operations on values, making other function calls
as well as combinations of all of the above.

The C standard specifies that argument expressions may be "evaluated"
(your "determine the value of" below) in any order. 'Expression
evaluation' can be considered a term-of-art in the computer science
"profession" which most understand to mean "determine the value of".





Given,
1) argument computation
2) argument passing order

Please describe _BOTH_ using "evaluated" in a sentence.

With "evaluated" meaning, respectively,
1) to determine the value of
2) to set the value of (specifically, to set the value of the
directional order)

One possible answer for both:
"The arguments must be evaluated right-to-left."

Context is necessary to determine if the meaning of "evaluated" is:
1) the ordering used to compute each of the arguments is from
right-to-left 2) the direction of argument ordering for argument
passing is to be right-to-left

The context of Walter Bright's post clearly indicates 2), as I
previously stated for Phil (which is 2) above) and originally.

You still seem to be missing the point. First, argument expression
evaluation can be done in any order. (Bright makes no reference to
this.)

Second, as to the "argument passing" order, this is defined by the
function prototype. (Bright makes no reference to this.)

Third, if you actually mean to refer to the order that the arguments
appear on (or are placed on) the x86 stack, that is not defined by the C
standard at all and a compiler is free to do whatever it likes as long
as when the called function refers to variables in its argument list, it
gets the correct value. The arguments may be passed in registers (as is
done on several other architectures) or on a stack (as is typically done
on x86) or via separately managed memory (I don't know of any
architecture that does this but it's certainly conceivable and would be
completely legal).

What comes to mind is an 8080 emulator running on an x86 executing an
emulation of an 8080 C compiler.

Walter Bright's article was not about any of these things but about how
the stack gets cleaned up on exit from a function call in certain x86
compiler implementations. I concede that this is certainly related to
how arguments are placed on the x86 stack but is orthogonal to
"ordering" (either the order of argument expression evaluation or the
order in which things are placed on the stack).

Finally, the word "evaluate" does not appear in Bright's article at all
nor is there any reference to either left-to-right or right-to-left
ordering (or even any appearance of the words 'left', 'right' or
'order').

This is why I fail to see how Bright's article says the things you seem
to think it says.

Well that whole thread, re:Bright's, stands on the notion of
implementations. So that, from that view, I see why RP says what he
does. As well, I value your comments, which stands on the notion of
the C Language. Any implementation stands in the light of the
Language Standard, obviously. But, I should think the underlying
notion of implementation should hold sway here on clax.

But continuing on in the notion of the C Language...
My question now turns to automatic variables. Does the notion of
scope of automatic variables in the language exhibit a 'concept of a
stack in the behaviour'?

Thanks,

Steve

GH- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Atomic operations in 32 and 64 bit platforms
    ... there is no general way for the compiler to know -- when compiling the ... called function -- how much space needs to be released from the stack. ... (I.e., a compiler can choose the best calling convention, which are 'C ... that's irrelevant to order of evaluation. ...
    (comp.lang.asm.x86)
  • Re: x86-64 and calling conventions
    ... good old 32-bit x86 convention. ... arguments would be passed on the stack (in good old linear ... That's kind of what I did in the Flaming Thunder compiler (which ... The calling convention is left-to-right (since I was making my own ...
    (comp.compilers)
  • Re: Atomic operations in 32 and 64 bit platforms
    ... a compiler to evaluate functions with fixed parameters in any order ... (i.e., cdecl in this ... evaluation can involve loading values from memory, ... appear on the x86 stack, that is not defined by the C ...
    (comp.lang.asm.x86)
  • Help on code generation and register allocation
    ... target architecture (X86) and then produce the code. ... Building the expression trees should not be too hard: ... a stack based intermediate language and I could use a "virtual stack" to ... I ordered the book Modern Compiler Design by Dick Grune yesterday. ...
    (comp.compilers)
  • Re: CLR stack
    ... "Value types on the stack" refers only to parameters and locals, ... code compiler. ... With CPU instructions that the CLR generates when it compiles the IL ... The x86 CPU models the top of stack as being the thing pointed to by the ...
    (microsoft.public.dotnet.general)