NetSWI* macro simplification

John Tytgat John.Tytgat at aaug.net
Thu Jan 24 15:35:52 PST 2002


In message <3C4FCEF3.8020708 at jeffray.co.uk> you wrote:

> John Tytgat wrote:
> 
> > The NetSWI* macros can be simplified.  See attachements.
> 
> I'm really sorry John, but I'm again going to have to voice my
> 'objections' to this change, too.

I have no problems with objections (as long the argumentation is
solid) ;-)

> I've spent a lot of time
> looking at this particular issue, talking to Stewart and to
> folks at RISCOS Ltd, and the issue really is still present in
> Internet Modules between 5.04 and 5.09 which are distributed as
> standard and a lot of people use these (RISC OS 4.0x)

How odd.  I too have asked this to Stewart on 5 Jan 2001 (not a typo,
yes, one year ago, shows how much I'm behind with my UnixLib updates)
and he replied quoting a totally different explanation (see
attachement).  BTW, my opening question in a private E-mail was:

] Something else, if I may : all Internet SWI's in UnixLib were wrapped
] in a couple of macro's which all had an SWI OS_EnterOS in front of them,
] i.e. they made sure that all Internet SWI's were called from a SVC26
] enviroment.  The motivation found in the code (clib/unixlib/asm_dec.s)
] was :
] 
] 	; NetSWI macro to call a networking (tcp/ip) swi.
] 	; We ensure that we are in SVC mode before calling the SWI because,
] 	; according to Stewart Brodie, certain versions of Acorn's Internet
] 	; stack require SWIs to be called in SVC mode.
] 
] When I asked more info about this in the UnixLib developer mailing
] list, Nick Burrett <mailto:nick at dsvr.net> replied in message
] <m38zp2hyhy.fsf at nick.ws.noc.dsvr.net> :
] 
] > In an earlier posting by Nick Clark, he mentions that version 5.04
] > corrupts r13_usr.  Apparently fixed in version 5.06 though.  One workaround
] > is to force users of UnixLib to ensure that they use Internet 5.06 or
] > above.  Then the hack could be removed.
] 
] I argumented that because the Internet SWI's in the 32-bit release of
] Acorn/Pace libraries didn't contain this hack either (ok I admit, I've
] disassembled them :-/), we can remove this hack in UnixLib.  Which I did.
] 
] Do you have any comments on this subject ? Let me know whether your
] thoughts on this may be shared in the UnixLib developer list and/or
] UnixLib release notes (when they are relevant of course).

And as I said in above paragraph, the 32 bit release of the Acorn/Pace
libraries do *NOT* have such a hack.  I would assume that if it was
that important, they would have added a similar hack.  How does this
get explained ?

> As a general point - the whole point of the NetSWI macro was to add
> this wrapping stuff, so if we aren't doing it, let's clean up the
> code "properly" and just call the SWIs directly and cleanly, rather
> via this macro which will now do nothing worthwhile.

I do not agree entirely.  The NetSWI* macro's are still handy as
their error handling is different than other SWI's.

> Now, I did try removing the horrible SVC wrappers around these
> SWI calls myself already, and no ill effects were observed, but
> I have it on STRONG recommendation from RISCOS Ltd that we keep
> the stuff in place as is.

But they released beta modules which do not have such a hack ?!

> I'm told (again, I have no evidence of my own) that the real issue
> here is that the internet SWIs somehow manage to return to the
> caller still in SVC mode, and not that they actually require to be
> put in SVC mode to call them.    (This is similar shitty behaviour
> to the Internet module's issue of sometimes calling it's Event
> handler with IRQs enabled!)
> 
> That's just my 2p worth, and you're welcome to take my opinion any
> way you like.   Personally, I'd like to see some proper evidence
> that these SWIs do manage to return in SVC mode before I really
> believe it, but I don't think these wrappers are doing too much
> harm, so being left in place isn't really hurting anyone too much,
> although I would like to see rid of them!  (Does that make sense?)

It's a philosophy : I'm more for cleaning up code unless we know for
sure certain hacks are needed.  Maybe the compromise is to make a
compile option to enable/disable this ?

> This change could have potentially devastating effects on stuff
> if it's wrong (machine goes pop ;) so could we collate all evidence
> and cover ground once again before any change is committed?

You have now Stewart's statement...

> Sorry :-(
> 
> Ian.
> 
> (PS: I don't think quoting a mail list message is good form in code,
> and I don't have a copy of that message anyway - could you forward
> it please? :)

That's the one in the attachment.  I don't know how much work it would
be for Nick to make the past UnixLib/GCC posts available.  Nick ? I
think that would be a good idea.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven
-------------- next part --------------
Return-Path: <unixlib-owner at hard-mofo.dsvr.net>
Received: from smtp.service.telerelay.com ([192.168.100.1]) by
          smstore1.service.telerelay.com (Netscape Messaging Server 4.15)
          with ESMTP id G6V9LY00.NR8 for <john.tytgat at village.uunet.be>;
          Tue, 9 Jan 2001 00:08:22 +0100 
Received: from ns0.entertainers.net ([213.38.93.2]) by
          smtp.service.telerelay.com (Netscape Messaging Server 4.15) with
          SMTP id G6V9LY02.78U for <john.tytgat at village.uunet.be>; Tue, 9
          Jan 2001 00:08:22 +0100 
Received: (qmail 18528 invoked by uid 9413); 8 Jan 2001 23:04:08 -0000
Delivered-To: acorn-John.Tytgat at aaug.net
Received: (qmail 18523 invoked from network); 8 Jan 2001 23:04:08 -0000
Received: from smtp-relay.noc.dsvr.net (212.69.192.4)
  by ns0.entweb.co.uk with SMTP; 8 Jan 2001 23:04:08 -0000
Received: from [212.69.195.137] (helo=hard-mofo.dsvr.net)
	by smtp-relay.noc.dsvr.net with esmtp (Exim 3.16 #1)
	id 14FlOc-000EIZ-00; Mon, 08 Jan 2001 23:08:10 +0000
Received: from tbd.uunet.be (root at tbd.uunet.be [194.7.1.10])
	by hard-mofo.dsvr.net (8.11.1/8.11.1) with ESMTP id f08N86I05909
	for <unixlib at hard-mofo.dsvr.net>; Mon, 8 Jan 2001 23:08:06 GMT
Received: from hobbes (uu212-190-9-212.unknown.uunet.be [212.190.9.212])
	by tbd.uunet.be (8.9.3/8.9.1) with SMTP id AAA05477
	for <unixlib at hard-mofo.dsvr.net>; Tue, 9 Jan 2001 00:08:01 +0100 (CET)
Date: Tue, 09 Jan 2001 00:15:15 +0100
From: John Tytgat <John.Tytgat at aaug.net>
To: unixlib at hard-mofo.dsvr.net
Subject: Re: UnixLib APCS-32 version ?
Message-ID: <4253de394a.Jo at village.uunet.be>
References: <4184cc2a4a.Jo at village.uunet.be> <m33dfvjpk2.fsf at nick.ws.noc.dsvr.net> <20001212173452.I91652 at plum.flirble.org> 
 <81c0fc2b4a.Jo at village.uunet.be> <m3vgsdhko6.fsf at nick.ws.noc.dsvr.net> <75a538334a.Jo at village.uunet.be> <m38zp2hyhy.fsf at nick.ws.noc.dsvr.net>
In-Reply-To: <m38zp2hyhy.fsf at nick.ws.noc.dsvr.net>
X-Organization: BASS
User-Agent: Messenger-Pro/2.10d (MsgServe/1.10) (RISC-OS/4.03) POPstar/2.02
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In message <m38zp2hyhy.fsf at nick.ws.noc.dsvr.net>
          Nick Burrett <nick at dsvr.net> wrote:

> >   * clib/unixlib/asm_dec.s contains several macro's for calling the
> >     Internet SWI's and those need to be revised too for the APCS32
> >     compliancy.  This would be rather easy if we could get rid of
> >     the OS_EnterOS SWI before each Internet SWI.  Does someone have more
> >     info on the next source comment ?
> > 
> > 	; NetSWI macro to call a networking (tcp/ip) swi.
> > 	; We ensure that we are in SVC mode before calling the SWI because,
> > 	; according to Stewart Brodie, certain versions of Acorn's Internet
> > 	; stack require SWIs to be called in SVC mode.
> > 
> >     Is this still relevant ? Does someone know which versions of
> >     Acorn's Internet stack are meant here ? Otherwise I would contact
> >     Stewart for more info.
> 
> In an earlier posting by Nick Clark, he mentions that version 5.04
> corrupts r13_usr.  Apparently fixed in version 5.06 though.  One workaround
> is to force users of UnixLib to ensure that they use Internet 5.06 or
> above.  Then the hack could be removed.

FYI, this seems to be the story (quoting Stewart Brodie with permission) :

> The problem is one of callbacks going off on exit from the Internet SWI.  The
> Internet module uses a single static error block to return error messages, so
> if your SWI fails, the error is placed in the block and the SWI returns. 
> BUT, as your SWI is returning to user mode with IRQs enabled, callbacks go
> off.  If a routine on a callback issues an Internet SWI and that wants to
> return an error, then the static error block is overwritten, that SWI exits,
> the callback exits, your code continues but finds a mysterious error in the
> error block that wasn't the error that actually occurred.
> 
> If you are in SVC mode when you call the SWI, your veneer to the Internet SWI
> gets to read the error number out of the error block before callbacks get a
> chance to go off.  In fact, callbacks will never go off as a result of such
> veneers because typically you return via MOVS pc, lr (26-bit) or by restoring
> the CPSR that you found on entry.
> 
> If you wanted to preserve the behaviour you'd be best off doing something
> like:
> 
>   MOV ip,sp
>   STMDB sp!, {r4-r9,fp,ip,lr,pc}
>   SUB fp, ip, #4
>   LDMIA ip, {r4-r6} ... however many of R4,R5 etc. are inputs to the SWI
>   MRS r9, CPSR
>   SWI OS_EnterOS
>   STR r9, [r13, #-4]!
>   SWI XInternet_blah
>   LDR r9, [r13], #4
>   MSR CPSR_c, r9
>   MOVVC r0, #0
>   LDRVS r0, [r0, #0]
>   LDRVS r9, =__errno
>   STRVS r0, [r9]
>   ... handle any other register outputs ...
>   LDMDB fp, {r4-r9,fp,sp,pc}
> 
> Is it worth it?  Probably not.  Current versions of Internet cycle through 4
> buffers.  I don't know when this become 4 though - our CVS logs don't go back
> that far as those ancient versions existed in a different source control
> system.
> 
> I did have a go at writing a version of Internet that used static errors for
> everything.  I think I must have deleted it though.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven


More information about the gcc mailing list