[gccsdk] OS_GPBP conundrum

[Gavin Wraith]

I have some code that uses OS_GPBP 12 to iterate
over objects in a directory, returning for each one
its name and filetype. It has been working for years
in RiscLua, when compiled with Norcroft and Objasm.
Now that I am using GCC the filetype is always
returned as zero, and I cannot see why.

OS_GPBP 12 uses a buffer to return its results,
with the object's name as a zero-terminated
string at buf+24, and the filetype in the word
at buf+20. I declare a buffer with

static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];

After the call to OS_GPBP 12 my code grabs the
name and filetype with

lua_pushstring(L, (char *)(_buf[6])); /* name */
lua_pushinteger(L, rdir_buf[5]);   /* file type */
return 2;  /* number of returned values */

This stuff is what makes the construction

   for name, ftype in dir (foo) do  end

work - well it used to The 'name' part comes out OK, but the
'ftype' is always zero, and I just cannot see why.

--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] OS_GPBP conundrum

[Nick Burrett]

On 21 September 2015 at 13:31, Gavin Wraith  wrote:

> I have some code that uses OS_GPBP 12 to iterate
> over objects in a directory, returning for each one
> its name and filetype. It has been working for years
> in RiscLua, when compiled with Norcroft and Objasm.
> Now that I am using GCC the filetype is always
> returned as zero, and I cannot see why.
>
> OS_GPBP 12 uses a buffer to return its results,
> with the object's name as a zero-terminated
> string at buf+24, and the filetype in the word
> at buf+20. I declare a buffer with
>
> static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];
>

^ shouldn't that be static int? Wouldn't the const imply that the buffer
never changes and could be liable to some optimisation in the way members
are accessed?


Nick
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] OS_GPBP conundrum

[Ralph Corderoy]

Hi Gavin,

> static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];
...
> lua_pushstring(L, (char *)(_buf[6])); /* name */
> lua_pushinteger(L, rdir_buf[5]);   /* file type */
> return 2;  /* number of returned values */
...
> The 'name' part comes out OK, but the 'ftype' is always zero, and I
> just cannot see why.

Sounds like rdir_buf is being re-used, but only the first 24 bytes of
it, trampling the filetype, but not the filename, before the push.  Do
you see filetype in rdir_buf[5] when you lua_pushinteger() above?  If
so, what happens between the push of the correct filetype and the pull
where it's wrong?  If not, show us the OS_GPBP 12 call?

Cheers, Ralph.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] OS_GBPB heeby jeebies

[Gavin Wraith]

By the way, I think I should have spelled it OS_GBPB. I always get this
wrong. Think 'heeby-jeeby'.

> ^ shouldn't that be static int? Wouldn't the const imply that the buffer
> never changes

The buffer doesn't change. It's its contents that change. I will try
removing the const.

> Sounds like rdir_buf is being re-used

The same code worked fine when compiled with Norcroft. With other stuff
omitted the code is:

#include sys.h

where sys.h contains:

  extern int rdir(const char *dir, const int *buf, int offset);

followed by:

static int rdir_iter (lua_State *L);
#define RDIR_BUFLEN 256
static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];

static int rdir_read  (lua_State *L) {
   lua_pushinteger(L,0); /* start */
   lua_pushstring(L,lua_tostring(L,1));
   lua_pushcclosure(L,_iter,2);
   return 1;
}

static int rdir_iter (lua_State *L) {
 int n;
 int offset = (int) lua_tointeger(L,lua_upvalueindex(1));
 const char * dir = lua_tostring(L,lua_upvalueindex(2));
 n = rdir(dir,rdir_buf,offset);
 if  (n == -1) {
lua_pushnil(L);
return 1;
   }
  else {
lua_pushinteger(L, n);
lua_replace(L, lua_upvalueindex(1));   /* new offset */
lua_pushstring(L, (char *)(_buf[6])); /* name */
lua_pushinteger(L, rdir_buf[5]);   /* filetype */
return 2;
  }
}

and where rdir is defined in sys.s by:

   .global rdir
   .set BUFLEN, 256

rdir:
  stmfd sp!,{r1-r6,r14}
  mov   r6,#0 @ no wild card
  mov   r5,#BUFLEN@ bufferlength
  mov   r4,r2 @ offset
  mov   r3,#1 @ number of items
  mov   r2,r1 @ buffer
  mov   r1,r0 @ directory name
  mov   r0,#12
  swi   0x2000c   @  XOS_GBPB
  movvs r3,#0
  cmp   r3,#1
  moveq r0,r4 @ next offset
  mvnne r0,#0 @ -1 if no more
  ldmfd sp!,{r1-r6,pc}
  .type rdir %function
  .size rdir, .-rdir

I am pretty sure that there is nothing wrong with rdir. After all,
the names are getting returned OK. Every time rdir is called from
within rdir_iter the buffer rdir_buf gets overwritten by the SWI.
That is how it is supposed to work. Nothing else messes with it.
You can forget about rdir_read; that is just the top level of the
C code called by RiscLua's riscos.dir function. The pages 2-70
and 2-71 in the PRMs explain what OS_GBPB is supposed to be doing.

Why are the filetypes coming out as zero, rather than some other value?
It has to be something trivial that I am not seeing. Actually, it does
not really matter; if I cut out the filetype part and just had the name
returned, that would be quite adequate for practical purposes. But then
I would still be left wondering why this code is not doing what is wanted.
--
Gavin Wraith (ga...@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] OS_GBPB heeby jeebies

[Ralph Corderoy]

Hi Gavin,

> > ^ shouldn't that be static int? Wouldn't the const imply that the
> > buffer never changes

This is the problem.

> The buffer doesn't change. It's its contents that change. I will try
> removing the const.

The buffer is its contents.  As an array rather than a pointer the
address of its first element will never change with or without the
const.  The const is saying the elements' values are constant.  Constant
at zero since it's a static and not initialised to anything else.

> Why are the filetypes coming out as zero, rather than some other
> value?

Because the compiler can assume the contents of a static const array
that's not initialised to anything are zero and doesn't need to load
from memory;  check the assembler.

Cheers, Ralph.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK