Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: printf() problem
Message-ID: <25411@amdcad.AMD.COM>
Date: 26 Apr 89 19:12:47 GMT
References: <11657@hodge.UUCP> <89Apr26.092233edt.18850@me.utoronto.ca>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 40
Summary:
Expires:
Sender:
Followup-To:

In article <89Apr26.092233edt.18850@me.utoronto.ca> zougas@hammer.me.UUCP (Athanasios(Tom) Zougas) writes:
| In article <11657@hodge.UUCP> jdm@hodge.UUCP (jdm) writes:
| C puts its function parameters on the stack in "reverse" order, i.e.
| the last item is on top (this allows variable number of parameters
| for user defined functions). Thus, the last item is accessed FIRST. So
| what is happening is the last getc(fp) is called first and hence the
| reversal.

No, the order of evaluation of function arguments is undefined -- the
notion of a stack does not necessarily exist.  See K&R C language
reference manual, section 7.1, or the pANS, section 3.3.2.2.

| >
| >    This happens in both Turbo C 2.0 and MS C 5.1.
| 
| It would happen in any C.

Function arguments *tend* to be evaluated in "reverse order" on systems
[meaning the combination of compiler and processor architecture] which
pass arguments on a memory stack, because it is sometimes easier. 
However, systems which pass arguments in registers may reverse this, and
optimizing compilers on certain processor architectures may take
advantage of the undefined order of evaluation to minimize execution
time by scheduling the use of processor resources.  For example, on the
Am29000, this sequence:

;f(int a, int *b, int c)
        sub     gr1,gr1,24
        asgeu   V_SPILL,gr1,gr126
        add     lr1,gr1,44
;{
;       return g(c+3,a-*b, *b);
        add     lr2,lr10,3	<-- c+3 evaluated first
        load    0,0,lr4,lr9	<-- then *b
        call    lr0,_g
        sub     lr3,lr8,lr4	<-- a-*b evaluated last

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)