linux-mips
[Top] [All Lists]

Re: implementation of software suspend on MIPS. (system log)

To: "J. Scott Kasten" <jscottkasten@yahoo.com>
Subject: Re: implementation of software suspend on MIPS. (system log)
From: "Hyon Lim" <alex@alexlab.net>
Date: Thu, 1 Nov 2007 23:37:51 +0900
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.64.0711010908090.11339@pixie.tetracon-eng.net>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <DDAE9570F73FC744918E843E20BE598B096E8E@server1.RightHand.righthandtech.com> <dd7dc2bc0710311846ve03e03eued4ed72c89b06e4f@mail.gmail.com> <Pine.SGI.4.60.0710312221360.4697@zeus.tetracon-eng.net> <dd7dc2bc0711010211k530296a4u8dc9272673075248@mail.gmail.com> <Pine.LNX.4.64.0711010908090.11339@pixie.tetracon-eng.net>
Sender: linux-mips-bounce@linux-mips.org
Thank you for comments.
The remain work of my software suspend on MIPS project is resume procedure.
I already confirmed that suspend function was work. (See my post which contains system log).
 
In an i386 implementation, there are only few assembly code for suspend and resume procedure.
So, my work will be similar with i386 implementation. Assembly code used in i386 implementation are several processor context related job
and copy saved page to memory. Instruction used in my MIPS implementation will be compatible to most of MIPS processor.
Because the instruction used in implementation is very basic (store and load and branch).
 
I agree your opinion related to maintainability and readability. So I implement my work with C and few assembly code.
Thank you for advice.
 
On 11/1/07, J. Scott Kasten <jscottkasten@yahoo.com> wrote:


On Thu, 1 Nov 2007, Hyon Lim wrote:

> I think the reason of assembly implementation is processor context
> replacement.

Understood.  Assembly may indeed be required for specific things like
restoring register state or fiddling with the cache if there aren't
already macros or functions in the kernel that do exactly what you need.

> The second reason that I thinking is calling convention of C language.

It's not uncommon at all to have assembly language glue, say between a
BIOS callback and the C language routine that does the work.

In your original post, you mentioned tracking variables and things that
suggested a module that does much more that just load some odd registers
or flip around a function call stack.  If that is indeed the case, then
for sake of maintainablility and readability, one would be strongly
encouraged to write the core stuff in plain old C and sprinkle in assembly
glue code as required.

Think about it this way.  MIPS is a pretty large family of CPUs, each with
it's own strange behaviors.  Several of those people on this list spend a
lot of time tweeking that assembly to make it work cleanly across various
CPUs.  It's a lot easier to understand 25 lines of assembly interface code
and 200 lines of C code, than an entire 1000 line module written in
assembly.  It's also a lot easier when you can shove most of the work over
to the compiler, especially if others like your work and want to
generalize it for use on many other MIPS CPUs.

I guess the real question here is how complex do you think your code needs
to be?  That should determine your path.

Regards,

-S-



--
Hyon Lim (임현)
Mobile. 010-8212-1240 (Intl' Call : +82-10-8212-1240)
Fax. 032-232-0578 (Intl' Available)
Homepage : http://www.alexlab.net
Blog : http://www.alexlab.net/blog
<Prev in Thread] Current Thread [Next in Thread>