* questions
@ 2008-05-26 0:32 Kevin Diggs
2008-05-25 21:31 ` questions Brad Boyer
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Diggs @ 2008-05-26 0:32 UTC (permalink / raw)
To: linuxppc-dev
Hi,
In idle_6xx.S one finds instructions like:
lis r4,powersave_nap@ha
lwz r4,powersave_nap@l(r4)
Can someone explain what this is doing? Presumably the first is loading
an address and the second a value. What do the '@ha' and '@l' do?
Also, is there any performance difference between:
lbz rD,d(rA)
lhz rD,d(rA)
lwz rD,d(rA)
While I'm wasting your time, I picked up an ADB infrared wireless
keyboard. I think it works. But not under Linux. Should it?
And is there any reason to prefer one over the other for doing byte
swapping:
lwbrx rD,rA,rB
stwbrx rS,rA,rB
kevin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: questions
2008-05-26 0:32 questions Kevin Diggs
@ 2008-05-25 21:31 ` Brad Boyer
0 siblings, 0 replies; 3+ messages in thread
From: Brad Boyer @ 2008-05-25 21:31 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev
On Sun, May 25, 2008 at 05:32:29PM -0700, Kevin Diggs wrote:
> Hi,
>
> In idle_6xx.S one finds instructions like:
>
> lis r4,powersave_nap@ha
> lwz r4,powersave_nap@l(r4)
>
> Can someone explain what this is doing? Presumably the first is loading
> an address and the second a value. What do the '@ha' and '@l' do?
The @ha and @l are modifiers to turn a 32 bit constant into a 16 bit
constant that would be useful in particular contexts. The @l takes
the low halfword, while the @ha takes the high halfword and modifies
it so that if you add in the low halfword you get the full 32 bit
value. There are other modifiers for other uses. You need these in
ppc assembly because there isn't any way to directly use a 32 bit
immediate value. In this particular case, it's taking advantage of
the indirect addressing modes to load a word from a constant 32 bit
address. It loads the high halfword of the pointer into r4 with the
lis instruction, then the low halfword is added during the effective
address calculation. The value at that constant address is loaded
into r4. Normally a 32 bit constant gets loaded with lis and addi,
but this is a way to avoid the extra instruction because it intends
to use the result as a pointer. The indirect addressing gives you
a free addi as long as you don't need to save the result.
> Also, is there any performance difference between:
>
> lbz rD,d(rA)
> lhz rD,d(rA)
> lwz rD,d(rA)
Normally you would use the one you need. I'd be surprised if there was
any difference in performance, but I also can't think of any reason
you would choose one over another for performance reasons even if there
was a difference.
> While I'm wasting your time, I picked up an ADB infrared wireless
> keyboard. I think it works. But not under Linux. Should it?
If it acts like a normal ADB keyboard, it should work. Does it need a
special driver with the MacOS? If so, then it would probably need a
custom driver in Linux as well.
Brad Boyer
flar@allandria•com
^ permalink raw reply [flat|nested] 3+ messages in thread
* questions
@ 1999-12-23 3:08 Ted Merrill
0 siblings, 0 replies; 3+ messages in thread
From: Ted Merrill @ 1999-12-23 3:08 UTC (permalink / raw)
To: linuxppc-embedded
First a general comment:
There were some good comments about board support packages in the
mail archive for this list.
Yes, i realize board support packages are a pain, however:
The linux kernel source is going to explode if it has to support
directly all of the board variations that will have linux ports.
Statements like "switch(machine_type)" won't cut it.
A more achievable goal is to have the kernel support directly
all of the common cpu chips, bus controllers and the like,
and configure the kernel with a combination of ifs and #ifs controlled
by configuration variables of fairly fine grain, selectable by
a board support configuration file that lives at a distance from
the rest of the code.
Now for the specific question of interest to me:
For the sort of projects that my company is working on,
vxWorks is a better fit than Linux because we don't really need
separate process/kernel address spaces.
What we're doing on the main processor isn't really that complicated
but does require IP networking... thus vxWorks or Linux.
We can (i hope) put up with this unwanted feature of Linux
in order to get the good stuff, principally the publicly developed
networking software and debugging tools.
I'm thinking the doable thing with Linux is to have only a single
process (filling in for the init process) with multiple threads.
Sounds like the "sash" program could be the beginning of the model for this.
The single process approach combined with static linking
blows away the whole problem of stripping down the C library to fit...
I was trying to make a list of processes running on my pc
that might be needed (and so would be a problem).
We won't have a local disk and we won't be serving very much
but we probably will want to serve both telnet (to a debugging shell, not sh)
and snmp for debug and management purposes, thus we may need inetd ...
this might be some amount of work to turn into library functions.
I'm pretty clueless how snmpd can be reasonably used in an embedded
system were some of the data is in a process and some in the kernel...
i'll have to read up more.
Can anyone share any experience with this?
Thanks
Ted Merrill
ArrayComm, Inc.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-05-26 2:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-26 0:32 questions Kevin Diggs
2008-05-25 21:31 ` questions Brad Boyer
-- strict thread matches above, loose matches on Subject: below --
1999-12-23 3:08 questions Ted Merrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox