On 2/3/07, Allen Briggs <briggs@netbsd.org> wrote:
> The immediate data in the instruction is only 16 bits.  So you can
> only load 16 bits at a time.

cool - thanks for the lesson :-)

In the meantime:

just a quick progress report and a few (2) questions :-)

Firstly, in case one needs a refresh info, the issue was that "blrl"
call in "operfirmware" method in powerpc/oea/ofw_subr.S was causing
bad things (e.g. decrementer exceptions)... the full sequence of calls
up to this "blrl" call is as follows:
__start (in macppc/macppc/locore.S)
which calls initppc (in macppc/macppc/machdep.c)
which calls oea_batinit (powerpc/oea/oea_machdep.c)
which calls mem_regions (powerpc/powerpc/ofw_machdep.c)
which calls OF_finddevice (powerpc/openfirm.c)
which calls openfirmware (powerpc/oea/ofw_subr.S)
and then in this openfirmware, the "blrl" call...


well... after comparing the ofw_subr.S file with the one from version
3, I have noticed that openfirware_entry has been made global instead
of local (which was done in the latest revision):

version 1.2, 2003/02/13 15:02:49 	version 1.3, 2006/08/05 21:26:49
Line 33:
         .local  openfirmware_entry 	         .globl  openfirmware_entry

After "reverting" (i.e. just making the "openfirmware_entry" .local
again), the problem dissapeared (there is another issue to which my
second question relates, but more on that later...)

Now, I don't know if that is just a "different location in memory"
thing (for instance I don't think that netbsd.map will have this
symbol after it has been declared .local), or the fact that gcc 4.1.2
(the netbsd-current compiler) might compile this thing differently
than gcc 3.3.3 (the v3 compiler)... so this is open to
interpretations... my first question, however, is:
"why was it made .globl in the first place?"

OK... now to the second question... :-)

The sequence of the calls this time is:

__start (in macppc/macppc/locore.S)
which calls initppc (in macppc/macppc/machdep.c)
which calls consinit (same file)
which calls cninit (same file)
which calls cninit_kd (same file)
which calls ofb_cnattach (macppc/dev/ofb_cons.c)
which calls OF_interpret (macppc/macppc/autoconf.c)

the question relates to va_arg macros...

the "ofb_cnattach", in the aforementioned sequence of calls, calls:

	/* get current cursor position */
	OF_interpret("line#", 1, 1, &crow);

the OF_interpret call is defined as:

int OF_interpret(const char *cmd, int nargs, int nreturns, ...)
{
	va_list ap;
	int i, len, status;
	static struct {
		const char *name;
		uint32_t nargs;
		uint32_t nreturns;
		uint32_t slots[16];
	} args = {
		"interpret",
		1,
		2,
	};

	ofw_stack();
	if (nreturns > 8)
		return -1;
	if ((len = strlen(cmd)) >= PAGE_SIZE)
		return -1;
	ofbcopy(cmd, OF_buf, len + 1);
	i = 0;
	args.slots[i] = (uint32_t)OF_buf;
	args.nargs = nargs + 1;
	args.nreturns = nreturns + 1;
	va_start(ap, nreturns);
	i++;
	while (i < args.nargs) {
		args.slots[i] = (uint32_t)va_arg(ap, uint32_t *);
		i++;
	}

	if (openfirmware(&args) == -1)
		return -1;
	status = args.slots[i];
	i++;

	while (i < args.nargs + args.nreturns) {
		*va_arg(ap, uint32_t *) = args.slots[i];
		i++;
	}
	va_end(ap);
	return status;
}

If I get it correctly (although my brain is rathre fried atm),
nargs is 1 and nreturns is 1 which means that
args.nargs is 2 and args.nreturns is 2 and their sum is 4 :-)

now, tracing the code in this OF_interpret after va_start(ap, nreturns):

- the first "while" loop will execute only once where the "va_arg"
macro will be called (thus iterating to the 1st argument positioned
AFTER the "nreturns").
- prior to second "while" loop beginning its activity, the "i" is 3.
- second "while" loop will execute at least once because, whilst i is
3, the args.nargs + args.nreturns is 4...
- during the execution of the second loop, the "va_arg" macro will be
called again... BUT... there is only 1 argument supplied to
OF_interpret after the "nreturns" ... ?!

So what is my overheated brain missing? :-)