Are PICs unlimited ;-)???

31 word stack is big. I started programming on a DDP machine from the 1960's that did not have a stack at all :-).

Of course, using malloc(), recursion or automatic (local on stack) variables or deeply nested functions are practically out of question on PIC18, but anyway, would you use those features in an assembly program ?

Other than those limitations, C is quite useful, e.g. hiding constant access from instruction space. It also makes easily readable and hence maintainable programs.

On a sunny day (2 Nov 2013 03:25:42 GMT) it happened Jasen Betts wrote in :

PIC18 config has this: ; Stack Full/Underflow Reset Enable bit: ; CONFIG STVREN = OFF ; Stack full/underflow will not cause Reset CONFIG STVREN = ON ; Stack full/underflow will cause Reset

I have it enabled, at least I notice something is wrong when developing.

On a sunny day (Sat, 02 Nov 2013 08:51:51 +0200) it happened snipped-for-privacy@downunder.com wrote in :

void my_function(int big) { int32t_t temp[4000000];

// blah blah }

Actually Linux will limit this, you will get a segfault if you claim too much stack.

// test60.c #include #include

int main(int argc, char **argv) { char temp[100000000]; fprintf(stderr, "Hello world\n");

exit(0); }

# gcc -o test60 test60.c # ./test60 zsh: segmentation fault ./test60

Is the (apparently 32 bit) Linux virtual address space that badly fragmented (as the 32 bit Windows map with dozens of DLLs loaded at scattered addresses), so you can not get at least 100 MB of contiguous virtual address space ?

Does

static char temp[100000000]; int main(int argc, char **argv) { fprintf(stderr, "Hello world\n"); exit(0); }

but

int main(int argc, char **argv) { auto char temp[100000000]; fprintf(stderr, "Hello world\n"); exit(0); }

doesn't ?

On a virtual memory machine, the heap typically starts just above the top of code/static data and grows towards higher virtual addresses. The stack typically start from the top (often at 2 GiB) and grows downwards.

A static 100 MB allocation will need 100 MB of contiguous virtual address space, but if this is available, is known at link time.

A 100 MB malloc() will also need 100 MB contiguous virtual memory. This is initially as non-accessible pages and a reference will cause a page fault and zeroed pages returned into the process working set. The next request for a 100 MB malloc() might return pages from completely different virtual addresses.

Depending on stack implementation, a primitive implementation might require that the addresses grow downwards and that contiguous virtual addresses are available. In such an implementation new zeroed pages are paged in at each nested function. This can continue as long as there are unused pages in the same virtual memory section as the original stack page.

In a more complex system, the system might not require contiguous stack space, but might be able to circumvent some used virtual space sections by declaring them as some dummy, unused stack variables.

Anyway, if a 100 MB auto variable allocation fails, using ten nested functions each allocating 10 MB might work in the latter case, but not in the primitive case.

On a sunny day (Sat, 02 Nov 2013 12:22:32 +0200) it happened snipped-for-privacy@downunder.com wrote in :

Segfaults too :-)

There is a huge amount of discussion on this topic (and the Linux user space stack) on google. I remember I ran into this problem many years ago, and asked in one of the groups, but cannot remember exactly what sets the limit.

I usually allocate a few kB for temp variables in functions, Stack is fast. This is a 64 bit processor but I am running a 32 bit kernel on it for compatibiliy....

The only 32 bit linux system I have easy access to is a Raspberry pi. it can malloc somewhere between 25000000 ans 26000000 bytes. on the other hand I can mmap 2147483647 bytes, which puts the largest contiguous block I could easily allocate at 2G

#include #include #include #include #include #include int main(int argc,char**argv) { int fd=open("bigfile",O_RDWR); if(argc) { void *p=mmap(NULL, (size_t) atoi(argv[1]) , PROT_READ | PROT_WRITE , MAP_SHARED, fd, 0); printf("s=%d fd=%d p=%p\n",atoi(argv[1]),fd,p); } return 0; }

after "ulimit -s unlimited" that ran fine on the raspberry pi, same with 250000000

--
For a good time: install ntp 

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

On a sunny day (2 Nov 2013 12:13:08 GMT) it happened Jasen Betts wrote in :

Ah, yes, that was the trick: ~ # ./test60 zsh: segmentation fault ./test60 ~ # ulimit -s unlimited ~ # ./test60 Hello world

I remember asking about that in comp.os.linux.development.apps, and got that answer, maybe even by you.

Of coure ulimit unlimited MAY get you into trouble elsewhere?

IBM mainframes (360 architecture) don't have stacks, either. ;-) No such concept.

you could say that an ARM7 have a one word stack, the link registers and th e program status registers

there are no automatic stacking it just by convention that R13 is normally used as a stack pointer

-Lasse

hi:there isproblemwithUndefined function 'lteRMC' for input arguments of type 'struct'.

Error in Untitled3 (line 39) rmc = lteRMC(enb, ncw);helpme

hi:there isproblemwithUndefined function 'lteRMC' for input arguments of type 'struct'.

Error in Untitled3 (line 39) rmc = lteRMC(enb, ncw);helpme

hi:there isproblemwithUndefined function 'lteRMC' for input arguments of type 'struct'.

Error in Untitled3 (line 39) rmc = lteRMC(enb, ncw);helpme