Email or username:

Password:

Forgot your password?
Top-level
Adrian Cochrane

@vertigo @millihertz Regarding that average basic-block size I had an interesting at-least-to-me solution for this usecase of parsing (which probably brings the average down), though I'm not sure how well it generalises.

What if we split the processor in 2 so half executes machine code that's near-entirely branches, thus relying mainly code density? And the other half primarily deals in straight-line code?

I saw a parser generator which included a tight-loop interpreter for such a machine.

2 comments
Adrian Cochrane

@vertigo @millihertz In otherwords: Yes, my hypothetical did rely on code-cache.

Even if I toyed with an alternate way of handling it!

Vertigo #$FF

@alcinnz @millihertz It's funny that you mentioned that. I have on several occasions exactly this, but we can actually generalize this. We can have one processor whose job it is to control computations from various "thread units". Each thread unit processes instructions in a straight ahead manner for as long as it can. The control processor then serves as a job coordinator. Performance can be enhanced by throwing more straight ahead thread units into the mix.

If the control program tries to launch more threads than or available in hardware, it'll block until a thread is completed its task. In this way, the control processor itself always appears to be single threaded.

@alcinnz @millihertz It's funny that you mentioned that. I have on several occasions exactly this, but we can actually generalize this. We can have one processor whose job it is to control computations from various "thread units". Each thread unit processes instructions in a straight ahead manner for as long as it can. The control processor then serves as a job coordinator. Performance can be enhanced by throwing more straight ahead thread units into the mix.

Go Up