Hi Sam,

I'd be glad to help out any way I can. My email address is at the end of the Hive document if you want to contact me. Hive can be freely used for commercial purposes, I'm just trying to give EEs who aren't working for the greater good a poke in the eye ;-)

Best,

Eric W.

Eric,

I started digging into compiler technology this week, and studying the register assignment problem got me thinking about your HIVE processor. Specifically, my question was whether or not it would be possible to even write a C-compiler that would compile code for the HIVE processor.

The HIVE is a very unique processor. As I understand it, each register is itself a stack. In many ways this makes the register assignment problem easier. Temporary variables are easy to come by, and once a variable ends up in the register stack it stays in "fast memory" or "register memory"--which for the HIVE is larger than it is for most other processor. These are all good and cool things. However, if each register's stack is limited to 32-entries deep--how would you handle an unknown number of procedure calls each placing an unknown number of values onto the stack?

A more traditional processor solves this problem by allocated more stack memory, storing some stack memory to the disk, or just busting the stack and breaking for which people have implemented stack checks. With the HIVE, however, without knowing how deep each stack is, how would you know what to save and when to do it? How would you know if you'd busted your stack? I suppose you could just answer that you never intend to build a compiler for your processor, or perhaps that you never intend to support any higher level languages, but ... Well, I'll let you respond as you see fit. Perhaps I haven't read deeply through the design document far enough to find this answer.

Thanks,

Dan

Hi Dan,

Sorry for my delay in replying, I don't make it to OC as often as I'd like lately.

There are register set bits for push and pop errors for each thread, but that's it so far. The stack levels could be reported through a register set mechanism, but I haven't implemented that as I don't anticipate needing to know stack depth for my applications. If you want to make a compiler why not have it keep track of stack depth used? You can easily track the levels in the simulator...

There is a manual method to check for stack depth: disable interrupts, do pushes one at a time while checking the push error bit, clear the bit when it errors, pop off the bogus pushed data, re-enable interrupts. Granted this is time consuming but what is the real point? You would need self-modifying code or something to implement it.

Stack depth should be more than enough for hand coding at the assembly level, if it's not then more BRAM should be assigned to the stacks, or the algorithm itself should be changed to fit the hardware.

Eric W.