sebastien.bourdeaud...@lekernel.net wrote:
> FN spawns a background compilation task with 64KB of stack (which
> could very well explain the crash):
> https://github.com/milkymist/flickernoise/blob/master/src/performance.c#L558
Ah yes, scribbling ~200 kB into nowhere land would indeed explain a
lo
On Sun, 02 Oct 2011 22:25:09 +0200, sebastien.bourdeaud...@lekernel.net
wrote:
On Sun, 2 Oct 2011 14:50:03 -0300, Werner Almesberger wrote:
The allocations are: 256036 bytes for struct sched_ctx and 2592
bytes for the struct vm_reg array. Does the compiler run in the
"GUI" task, which has about
On Sun, 2 Oct 2011 14:50:03 -0300, Werner Almesberger wrote:
The allocations are: 256036 bytes for struct sched_ctx and 2592
bytes for the struct vm_reg array. Does the compiler run in the
"GUI" task, which has about 1 MB of stack, or somewhere else ?
FN spawns a background compilation task wit
Hmm, I converted lnfpus to allocate things on the stack, but
RTEMS doesn't seem to be happy with this - either the compiler
gets stuck or the entire system hangs.
The same code runs fine on Linux and also passes valgrind.
The allocations are: 256036 bytes for struct sched_ctx and 2592
bytes for t
On 10/01/2011 02:40 PM, Werner Almesberger wrote:
Okay. How do I build and test that demo firmware ?
Easy, just use the "build_demo.sh" script in the SoC sources. This
generates software/demo/boot.bin.
___
http://lists.milkymist.org/listinfo.cgi/d
S?bastien Bourdeauducq wrote:
> Could you keep sc and sc->regs (you can use alloca() - just #define
> it to __builtin_alloca in the demo firmware) on the stack?
Okay. How do I build and test that demo firmware ?
It seems that clang supports dynamic arrays (like gcc does),
so perhaps just declarin
Hi,
Thanks. I committed it, however there is a little problem that is best
addressed with a second patch imo:
Could you keep sc and sc->regs (you can use alloca() - just #define it
to __builtin_alloca in the demo firmware) on the stack? This way:
* the scheduler stays reentrant
* we do not h
I did a bit more cleanup and checked for low-hanging fruits for
further optimization (didn't find any, see below), and I think
the improved scheduler is now good for regular use:
http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/perf/sched.c
I just keep the LCPF (Longes
