Tech Insider					     Technology and Trends


		       LUGNET Mailing List Archives

Xref: lugnet.com lugnet.robotics:1362
Newsgroups: lugnet.robotics
Path: lugnet.com!lugnet
From: lego-robotics@crynwr.com (Markus L. Noga)
Subject: legOS-0.1.4
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: mlnoga@inrialpes.fr
X-Nntp-Gateway: lego-robotics@crynwr.com
Organization: INRIA Rhone-Alpes / IPR Uni Karlsruhe
Message-ID: <36728D8E.88F803@inrialpes.fr>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.119 i686)
Mime-Version: 1.0
X-Nntp-Posting-Host: lugnet.com
Date: Sat, 12 Dec 1998 15:36:46 GMT
Original-From: "Markus L. Noga" <Markus.Noga@inrialpes.fr>
Lines: 20

Hi,

as you might guess by the date, it's raining in Grenoble, so I'm not
romping about in the mountains.

Matt suggested I check out the register clobbers in ROM calls with a
disassembler, and how right he was. gcc doesn't make the slightest
effort to save and restore registers. I fixed that, the system should be
more stable now.

http://mauve.inrialpes.fr/legOS/

Rotation sensors are still not validated. Please do if you have any.

Markus.

-- 
Markus L. Noga			noga@inrialpes.fr
INRIA Rhône-Alpes		http://www.inrialpes.fr/
IPR Universität Karlsruhe   	http://wwwipr.ira.uka.de/

Xref: lugnet.com lugnet.robotics:1405
Newsgroups: lugnet.robotics
Path: lugnet.com!lugnet
From: lego-robotics@crynwr.com (Kekoa Proudfoot)
Subject: Re: legOS-0.1.4
X-Nntp-Gateway: lego-robotics@crynwr.com
Organization: Stanford University
Message-ID: <199812140835.AAA07449@pixel.Stanford.EDU>
References: <36728D8E.88F803@inrialpes.fr>
X-Nntp-Posting-Host: lugnet.com
Date: Mon, 14 Dec 1998 08:35:36 GMT
Original-From: Kekoa Proudfoot <kekoa@Graphics.Stanford.EDU>
Lines: 60

Hi Markus,

You wrote:
>Matt suggested I check out the register clobbers in ROM calls with a
>disassembler, and how right he was. gcc doesn't make the slightest
>effort to save and restore registers. I fixed that, the system should be
>more stable now.

The GNU info pages regarding the usage of __asm__ say:

     It is up to you to make sure that the assembler names you choose do
  not conflict with any other assembler symbols.  Also, you must not use a
  register name; that would produce completely invalid assembler code.

  (Last paragraph of the GCC -> C Extensions -> Asm Labels info page.)

This seems to explain some of the problems you seem to be having regarding
clobbering of registers, specifically, one of those that you mention in
your log book on your web page.

From my brief experience with GCC this afternoon, and from the information
in the info files regarding this topic, it seems to me that __asm__ is
basically a template mechanism.  GCC puts no intelligence into it at all.
So when you do something like:

  register unsigned _asdf __asm__ ("r6");

you cause _asdf to be referenced in assembly by the name r6; however, the
compiler does no interpretation on that name, and therefore does not notice
that it also uses that name for something else, namely register 6.

I don't think the inline assembly mechanism is as flexible as you'd like it
to be.

On the other hand, I have yet to see a case where something like

  __asm__ __volatile__ ("mov.w #0x1234,r6":::"r6");

fails to work.  For example:

  int test (int foo) {
      __asm__ volatile ("mov #0x0:0,r0" : : : "r0");
      return foo + 1;
  }

generates:

_test:
        push    r6
        mov.w   r7,r6
        mov.w   r0,r2
        mov #0x0:0,r0
        adds #1,r2
        mov.w   r2,r0
        pop     r6
        rts

It looks like r0 is indeed saved so that the return value is correct.

-Kekoa

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/