[9fans] pcc limitation?

[9fans] pcc limitation?

[Carl-Daniel Hailfinger]

Hi,

any idea why the code below causes an error message from pcc? I'm trying
to port flashrom to Plan 9, but I've been fighting the compiler for the
last few hours.
/usr/glenda/flashrom/test3.c:20[stdin:45] constructor must be a structure
/usr/glenda/flashrom/test3.c:25[stdin:50] constructor must be a structure

Regards,
Carl-Daniel

#include <stddef.h>

#define JEDEC_WREN              0x06
#define JEDEC_WREN_OUTSIZE      0x01
#define JEDEC_CE_C7             0xc7
#define JEDEC_CE_C7_OUTSIZE     0x01

struct spi_command {
        unsigned int writecnt;
        unsigned int readcnt;
        const unsigned char *writearr;
        unsigned char *readarr;
};

void spi_chip_erase_c7(void)
{
        struct spi_command cmds[] = {
        {
                .writecnt       = JEDEC_WREN_OUTSIZE,
                .writearr       = (const unsigned char[]){ JEDEC_WREN },
                .readcnt        = 0,
                .readarr        = NULL,
        }, {
                .writecnt       = JEDEC_CE_C7_OUTSIZE,
                .writearr       = (const unsigned char[]){ JEDEC_CE_C7 },
                .readcnt        = 0,
                .readarr        = NULL,
        }, {
                .writecnt       = 0,
                .writearr       = NULL,
                .readcnt        = 0,
                .readarr        = NULL,
        }};
}

Re: [9fans] pcc limitation?

[Federico G. Benavento]

the syntax (){} is for structures, like (Point){0, 0} or something,
so you don't need the braces there, just the cast

               .writearr       = (const unsigned char*)JEDEC_WREN,



On Sat, Nov 6, 2010 at 9:56 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> Hi,
>
> any idea why the code below causes an error message from pcc? I'm trying
> to port flashrom to Plan 9, but I've been fighting the compiler for the
> last few hours.
> /usr/glenda/flashrom/test3.c:20[stdin:45] constructor must be a structure
> /usr/glenda/flashrom/test3.c:25[stdin:50] constructor must be a structure
>
> Regards,
> Carl-Daniel
>
> #include <stddef.h>
>
> #define JEDEC_WREN              0x06
> #define JEDEC_WREN_OUTSIZE      0x01
> #define JEDEC_CE_C7             0xc7
> #define JEDEC_CE_C7_OUTSIZE     0x01
>
> struct spi_command {
>        unsigned int writecnt;
>        unsigned int readcnt;
>        const unsigned char *writearr;
>        unsigned char *readarr;
> };
>
> void spi_chip_erase_c7(void)
> {
>        struct spi_command cmds[] = {
>        {
>                .writecnt       = JEDEC_WREN_OUTSIZE,
>                .writearr       = (const unsigned char[]){ JEDEC_WREN },
>                .readcnt        = 0,
>                .readarr        = NULL,
>        }, {
>                .writecnt       = JEDEC_CE_C7_OUTSIZE,
>                .writearr       = (const unsigned char[]){ JEDEC_CE_C7 },
>                .readcnt        = 0,
>                .readarr        = NULL,
>        }, {
>                .writecnt       = 0,
>                .writearr       = NULL,
>                .readcnt        = 0,
>                .readarr        = NULL,
>        }};
> }
>
>
>
>



-- 
Federico G. Benavento

Re: [9fans] pcc limitation?

[Carl-Daniel Hailfinger]

On 07.11.2010 05:02, Federico G. Benavento wrote:
> the syntax (){} is for structures, like (Point){0, 0} or something,
> so you don't need the braces there, just the cast
>
>                .writearr       = (const unsigned char*)JEDEC_WREN,
>

writearr should point to a one-member const unsigned char array, and the
zeroth element of that array has the value JEDEC_WREN.

Your suggested code has different behaviour (it casts a uchar to uchar *):

#include <stddef.h>
#include <stdio.h>
#define JEDEC_WREN              0x06
struct spi_command {
        const unsigned char *writearr;
};
int main(int argc, char *argv[])
{
        struct spi_command cmds[] = {
        {
                .writearr       = (const unsigned char[]){ JEDEC_WREN },
        },{
                .writearr       = (const unsigned char *)JEDEC_WREN,
        }};
        printf("Mine: writearr=%p\n", cmds[0].writearr);
        printf("Mine: writearr[0]=0x%02hhx\n", cmds[0].writearr[0]);
        printf("Federico: writearr=%p\n", cmds[1].writearr);
        printf("Federico: writearr[0]=0x%02hhx\n", cmds[1].writearr[0]);
        return 0;
}

Output is:
Mine: writearr=0xbf8eb213
Mine: writearr[0]=0x06
Federico: writearr=0x6
Segmentation fault

Regards,
Carl-Daniel

--
http://www.hailfinger.org/

Re: [9fans] pcc limitation?

[erik quanstrom]

> writearr should point to a one-member const unsigned char array, and the
> zeroth element of that array has the value JEDEC_WREN.
=
it's not clear to me that c99 allows one to declare an unnamed array
and assign a pointer to it in this way except if the array is a char* or
wchar_t*.

i think the cleanest approach to solving your problem is
to define writeattr as an array, not a uchar*.

- erik

----
8c -FVTw cdha.c
8l -o 8.cdha cdha.8

#include <u.h>
#include <libc.h>

enum{
	Jwren	= 0x06,
};

typedef struct Spicmd Spicmd;
struct Spicmd{
	uchar	writearr[5];
};

void
main(void)
{
	Spicmd cmds[] = {
		{
		.writearr		= {Jwren, },
		},
	};

	print("writearr=%p\n", cmds[0].writearr);
	print("writearr[0]=%#.2hhx\n", cmds[0].writearr[0]);
	exits("");
}

Re: [9fans] pcc limitation?

[Carl-Daniel Hailfinger]

On 07.11.2010 15:46, erik quanstrom wrote:
>> writearr should point to a one-member const unsigned char array, and the
>> zeroth element of that array has the value JEDEC_WREN.
>>
> =
> it's not clear to me that c99 allows one to declare an unnamed array
> and assign a pointer to it in this way except if the array is a char* or
> wchar_t*.
>
> i think the cleanest approach to solving your problem is
> to define writeattr as an array, not a uchar*.
>

The big problem with defining it as an array inside struct spicmd is
that writearr has variable length. writearr is a command sent to a SPI
chip by a SPI controller. writearr can have any length of 1-1056 bytes.
There's also an analogous readarr in struct spi_command (not mentioned
in the example to keep it brief) and that one can have any length
between 0 and 16777217 (2^24+1) bytes. One variable-length array at the
end of a struct is possible, but an array of structs with a variable
length array in the struct won't work since you can't compute the offset
of individual members of the outer arrray.

The only solution I can see is this:

#define JEDEC_WREN              0x06
#define JEDEC_SE                0x20
struct spi_command {
        const unsigned char *writearr;
};
int main(int argc, char *argv[])
{
	const unsigned char writearr_helper1[] = { JEDEC_WREN };
	const unsigned char writearr_helper2[] = { JEDEC_SE, 0x01, 0x23, 0x45 };
        struct spi_command cmds[] = {
        {
                .writearr       = writearr_helper1,
        },{
                .writearr       = writearr_helper2,
        }};
        /* ... */
}


That solution wastes variables and is generally pretty ugly.
I still hope we can find a better solution.

Regards,
Carl-Daniel

--
http://www.hailfinger.org/

Re: [9fans] pcc limitation?

[erik quanstrom]

> The big problem with defining it as an array inside struct spicmd is
> that writearr has variable length. writearr is a command sent to a SPI
> chip by a SPI controller. writearr can have any length of 1-1056 bytes.
> There's also an analogous readarr in struct spi_command (not mentioned
> in the example to keep it brief) and that one can have any length
> between 0 and 16777217 (2^24+1) bytes. One variable-length array at the
> end of a struct is possible, but an array of structs with a variable
> length array in the struct won't work since you can't compute the offset
> of individual members of the outer arrray.

what is the largest sequence of commands in practice?

- erik

Re: [9fans] pcc limitation?

[Carl-Daniel Hailfinger]

On 07.11.2010 19:26, erik quanstrom wrote:
>> The big problem with defining it as an array inside struct spicmd is
>> that writearr has variable length. writearr is a command sent to a SPI
>> chip by a SPI controller. writearr can have any length of 1-1056 bytes.
>> There's also an analogous readarr in struct spi_command (not mentioned
>> in the example to keep it brief) and that one can have any length
>> between 0 and 16777217 (2^24+1) bytes. One variable-length array at the
>> end of a struct is possible, but an array of structs with a variable
>> length array in the struct won't work since you can't compute the offset
>> of individual members of the outer arrray.
>>
>
> what is the largest sequence of commands in practice?
>

In practice:
Right now (with incomplete support for some chips):
writearr: 260 bytes
readarr: 16777217 bytes

In the near future (maybe 2 weeks from now):
writearr: 1056 bytes
readarr: 16777217 bytes

The theoretical limit for readarr is unlimited, and we're already seeing
prototypes of chips which would benefit from readarr size above 16 MB.
The theoretical limit for writearr is around 16 MB as well, but I've not
seen hardware requiring that (yet).

readarr size depends on the host and the hardware and can be limited
dynamically. For some hardware it is essential to maximize readarr to
get reasonable speed (we're talking about a slowdown factor of 1000 for
small readarr vs. large readarr).

Given that flashrom also runs in resource-constrained environments (32
kB RAM), we determine readarr size at runtime based on resource
constraints. However, given that the call graph which passes struct
spi_command along can easily reach 5 or 6 levels (keeping each function
minimal to avoid code duplication), passing a full array instead of a
pointer via the stack means we have a copy overhead of
sizeof(readarr)-sizeof(void*) plus sizeof(writearr)-sizeof(void*).

Regards,
Carl-Daniel

--
http://www.hailfinger.org/

Re: [9fans] pcc limitation?

[erik quanstrom]

> In practice:
> Right now (with incomplete support for some chips):
> writearr: 260 bytes
> readarr: 16777217 bytes
>
> In the near future (maybe 2 weeks from now):
> writearr: 1056 bytes
> readarr: 16777217 bytes

so you're saying that you have > 16777217 bytes of spi data for a single
command in your program?  i think i'm missing something.  you couldn't
fit that much data in 32kb of ram.

- erik

Re: [9fans] pcc limitation?

[Carl-Daniel Hailfinger]

On 07.11.2010 20:42, erik quanstrom wrote:
>> In practice:
>> Right now (with incomplete support for some chips):
>> writearr: 260 bytes
>> readarr: 16777217 bytes
>>
>> In the near future (maybe 2 weeks from now):
>> writearr: 1056 bytes
>> readarr: 16777217 bytes
>>
>
> so you're saying that you have > 16777217 bytes of spi data for a single
> command in your program?

You asked for "the largest sequence of commands in practice". That's why
I assumed you wanted to know about the largest command in all environments.


> i think i'm missing something.  you couldn't
> fit that much data in 32kb of ram.
>

Correct. Please see the following quote from my mail:

>> we determine readarr size at runtime based on resource constraints.

In hosted environments with sufficient resources (e.g. Plan 9), the
largest command response can indeed be ~16 MBytes. In
resource-constrained environments we limit command+response size to 260
bytes or even less. And depending on the programmer hardware, there may
be additional constraints (e.g. commands having exactly 1,2,4 or 5 bytes
and no other lengths) regardless of available resources.

If you want to take a look at the context of the code which prompted
this mail thread, please see
http://www.flashrom.org/trac/flashrom/browser/trunk/spi25.c#L594
spi_chip_erase_c7, spi_block_erase_52 and spi_nbyte_program all use the
spi_send_multicommand interface which takes an array of struct
spi_command as parameter (submission of multiple commands at once).
spi_nbyte_read uses the spi_send_command interface which takes the
individual members of struct spi_command as parameters (submission of a
single command).
We would love to use a common interface for command submission
regardless of the number of commands being sent (and we had such an
interface in the past), but sadly some supported hardware enforces
combined commands and other hardware enforces separate commands. The
individual programmer drivers take care of translating the requests to
the format usable by the programmer hardware.

Hardware programming is fun. Side effects include nausea and vomiting.

I hope this answers your questions.

Regards,
Carl-Daniel

--
http://www.hailfinger.org/

Re: [9fans] pcc limitation?

[erik quanstrom]

> Hardware programming is fun. Side effects include nausea and vomiting.

you're doing it wrong.

:-)

- erik

Re: [9fans] pcc limitation?

[Julius Schmidt]

>> Hardware programming is fun. Side effects include nausea and vomiting.
>
> you're doing it wrong.
>
> :-)
>
> - erik
>
>

Just run Plan 9 on the hardware. Who wanted to create "Plan 9 from 8-bit
space"? Let's do it for AVR.
Then mount LEDs and the like...

aiju

Re: [9fans] pcc limitation?

[erik quanstrom]

> Just run Plan 9 on the hardware. Who wanted to create "Plan 9 from 8-bit
> space"? Let's do it for AVR.
> Then mount LEDs and the like...

that's pretty impractical.  letting alone the type hell one would
have in porting a c compiler, i don't know of any 8 bit parts with
an mmu, and the avr is especially difficult, being a harvard
arch chip with program memory only in flash.

a more fruitful approach would be to write an assembler and
simulator, then an event loop to poll devices and serve an
external interface (9p or simplier, depending on how stupid
the chip is. :-)) which one could read from a machine with
more brains, a plan 9 box.

jeff sickel is working with pics and other tiny controllers.  see
the resonance tracking paper and slides at http://5e.iwp9.org/
and the work in progress at http://4e.iwp9.org/

- erik

Re: [9fans] pcc limitation?

[Anthony Sorace]

Anyone considering things like that should also be familiar with the "Styx on a Brick" work, where the Vita Nuova guys stuck a Styx interface on a Lego mindstorm controller brick. The interface layering from the raw serial interface up through something which you wrote times to (and the clickable GUI on top of that) remains a really great illustration.

On Nov 8, 2010, at 9:00, erik quanstrom <quanstro@quanstro.net> wrote:

>> Just run Plan 9 on the hardware. Who wanted to create "Plan 9 from 8-bit
>> space"? Let's do it for AVR.
>> Then mount LEDs and the like...
> 
> that's pretty impractical.  letting alone the type hell one would
> have in porting a c compiler, i don't know of any 8 bit parts with
> an mmu, and the avr is especially difficult, being a harvard
> arch chip with program memory only in flash.
> 
> a more fruitful approach would be to write an assembler and
> simulator, then an event loop to poll devices and serve an
> external interface (9p or simplier, depending on how stupid
> the chip is. :-)) which one could read from a machine with
> more brains, a plan 9 box.
> 
> jeff sickel is working with pics and other tiny controllers.  see
> the resonance tracking paper and slides at http://5e.iwp9.org/
> and the work in progress at http://4e.iwp9.org/
> 
> - erik

Re: [9fans] pcc limitation?

[Russ Cox]

> That solution wastes variables and is generally pretty ugly.
> I still hope we can find a better solution.

You can't.  C doesn't work that way.
Your choices are to use a fixed-size array or to
declare helper arrays as you have already done.
You can use string literals as aliases for helper
arrays, but that's probably even worse.

#define JEDEC_WREN "\x06"
#define JEDEC_SE "\x20"

... cmds[] = {
    { .writearr = (uchar*)(JEDEC_WREN) },
    { .writearr = (uchar*)(JEDEC_SE "\x01\x23\x45") },
    ...
}

If that's enough to turn your stomach, then your
only remaining alternative is to write a program to
generate the code for you using helper arrays.

Russ