9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] pcc limitation?
Date: Sun,  7 Nov 2010 20:36:52 +0100	[thread overview]
Message-ID: <4CD6FFD4.9040502@gmx.net> (raw)
In-Reply-To: <1ab89ced7625309d8c289292c4a4086c@brasstown.quanstro.net>

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/




  reply	other threads:[~2010-11-07 19:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-07  0:56 Carl-Daniel Hailfinger
2010-11-07  4:02 ` Federico G. Benavento
2010-11-07 12:32   ` Carl-Daniel Hailfinger
2010-11-07 14:46     ` erik quanstrom
2010-11-07 16:22       ` Carl-Daniel Hailfinger
2010-11-07 18:26         ` erik quanstrom
2010-11-07 19:36           ` Carl-Daniel Hailfinger [this message]
2010-11-07 19:42             ` erik quanstrom
2010-11-08  0:16               ` Carl-Daniel Hailfinger
2010-11-08  0:56                 ` erik quanstrom
2010-11-08  9:39                   ` Julius Schmidt
2010-11-08 14:00                     ` erik quanstrom
2010-11-08 15:17                       ` Anthony Sorace
2010-11-08  2:58         ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD6FFD4.9040502@gmx.net \
    --to=c-d.hailfinger.devel.2006@gmx.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).