[sdcc-devel] Arrays + memory modifier + parameter

[Johan K. <joh...@id...>]

Yes, this is bug #436360.

> int xdata Array1Glob[2];
>
> void
> f2 (int xdata Array1Par[2])
>

>   Array1Par[1] = 2;
> }
>
> SDCC stores _f2_Array1Par_1_1 in xdata instead of data.

There is no way to specify where the pointer that could be needed to pass
Array1Par as a parameter should reside. Until now it used the same storage
as the array itself. Now it is the default space for the port, so
that --model-small can keep it registered (no storage required) and other
ports aren't affected (although I don't see why --model-large still requires
storage, -mds390 doesn't).

> void
> f3 (int Array1Par[2])
>

>   Array1Par[0] = 1;
> }
>
> void
> f1 (void)
>

>   f2 (Array1Glob);
>   f3 (Array1Glob);
> }
>
> No warning when calling f3.

That one is tricky. The defined parameter of f3 is: "data int * data
defParm" (assuming --model-small). The actual parameter when f3 is called
is: "xdata int actParm[]". Now compareType() doesn't know how to handle this
and bails out, saying ok: ptr, array, what the heck: castable.
The whole problem is the array declarator. I don't see any reason why an
array just shouldn't be a pointer with (or without) a number of elements. So
that compareType() could do what it is suppost to do: check the COMPLETE
type chain. If I don't hear why I shouldn't I will make it so.

> Another problem:
>
> typedef int Array1Dim[51];
> xdata Array1Dim Array1Glob;
>
> void
> f4 (xdata Array1Dim Array1Par)
>

>   Array1Par[1] = 1;
> }
>
> void
> f5 (void)
>

>   f4 (Array1Glob);
> }
>
> error: *** two or more storage classes in declaration for
'type_specifier_list'

Fixed in the typedef handling in SDCC.y. This could also fix some other bug
reports, haven't checked that yet.

Johan