EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: DiTBho on December 29, 2020, 02:42:58 pm
-
so, I have here a PPC-like simulator where the deepest function call is only 32.
Every task and even the kernel can have a maximum of 32 nested function calls on its function tree.
The Kernel and exception can also invoke up to two "fast leaf" functions, and in this case you have up to 2 extra function calls, jfl0 and jfl1, which both save the RA in a private register.
So jfl0 saves its return address in RA0, while jfl1 saves it in RA1
Would you program such CPU? Perhaps for anything embedded rather than for a GP computer?
I still have to understand why the author/authors did it this way. Unfortunately I haven't yet reached him/her/them by email.
-
It's a software simulator, so this afternoon I checked the source code and found the limitation is just a counter that increments each time "jump and link" is invoked, and decrements each time "j RA" is invoked.
It can be disabled and removed from the CPU_simulator, just ... I wonder would someone program a CPU that only allows a limited number of nested function call?
Are there examples of real CPUs with this "feature" (let's call it "feature") implemented in hardware?
-
Certainly. Anything with a hardware stack fits the bill. PIC for example.
Perhaps related, anything with stack registers, i8087 for instance (which however isn't a standalone CPU).
I don't think any commercial GP computers have used one [as main CPU]. Game consoles, who knows, but not the big ones at least. Perhaps some hobbyists have forced CPUs into such service, but there's a lot of overhead associated with it (as you note, saving the stack to main memory).
Removing it from the simulator would not be a great idea, if there was a purpose for it being there. Obviously, if this emulates a real device, it'll be incompatible with it. If the purpose is to illustrate physically realizable architectures, an apparently unlimited memory store wouldn't make sense.
Tim
-
32 levels of function call is pretty deep for anything that isn't Java and/or recursive.
It's probably to catch bugs.
-
I wonder would someone program a CPU that only allows a limited number of nested function call?
Depends on the application, and more importantly, how it handles the "overflow". Obviously you'd need to be pretty careful never to reach the limit. But if said CPU would (for instance) generate an exception in case of "return stack overflow", then why not. Now if there was no exception system and no means of knowing it happened, then it's a lot more questionable. In any case, for any moderately complex software, you need to ensure from static analysis that the max call depth never reaches the maximum.
Are there examples of real CPUs with this "feature" (let's call it "feature") implemented in hardware?
Yes of course, as I mentioned in another thread, some PIC MCUs, for instance, do have a hardware return stack. The smallest being 8-entry deep AFAIR. And they didn't have any means of knowing in case of overflow, although I may have forgotten. I have programmed such MCUs and they are usable, but you need to be very careful. Of course software for those MCUs tends to be relatively simple, and written either in assembly or in C, but with proper care.
If you think about it, call depth is ALWAYS limited, even with a conventional stack system, given that the stack itself in this case is itself limited. Of course, unless you use a lot of local data, even with relatively small stacks, the max call depth is usually a lot more than 8, or even 32.
Anyway, that's linked to the talk about dedicated return stacks, and I find the idea interesting (as already said), but I certainly would much prefer return stacks to be configurable rather than fixed.
Although such limits can be annoying, they can also be useful to track issues with your code, especially if the actual call depth is higher than what you expected. But as I said, I personally think that would be more useful yet if that can be configured depending on the application.
To get an idea of the max call depth in your programs, you can instrument the code to figure it out. That can be an interesting experience.
-
It's probably to catch bugs.
yup, I looked into the git stuff and found a note in an old branch.
It got lost in recent branches, but it explicitly says it: done to catch bugs
Bingo! we catched it :D