In that CALLVEC is new, question asked even once is relatively frequent. So here goes with some asked so far:
Q1) Why has CALLVEC been called "The Swiss Army Knife Of Instructions"?
A1) Because I thought it was an apt description.
Q2) Why was the instruction called CALLVEC?
A2) Because TSAKOI was too hard for me to pronounce.
And because its primary use is expected to be a VECtored CALL;
VECCALL was ignored as ambiguous; too hard to spell and pronounce.
The vector calling allows for the Application Execution Environment to tailor the instruction to specific hardware.
Q3) WHAT DOES IT LOOK LIKE (instruction format).
A3) The final instruction format has not been determined yet,
but its logical structure is < OPCODE>.
Q4) Where is CALLVEC used.
A4) CALL VEC should always be used in a call context.
The instruction always writes t0 [ this may be refined to another
Q) HOW DOES IT WORK (What does it do)
A)
Minimally, the hardware implemented CALLVEC:
a) stores the instruction info into t0 [when emulated it stores the instruction word]
b) it formats the instruction code format into a 17bit unsigned immediate into t0
c) it conditionally stores the return address into ra [depending upon immediate value]
d) if ra was stored it conditionally ra
Q: Is that all?
A: No, standard hardware optimizations can be made that because they are in "library routines" are transparent to the application code. Further, some of the more sophisticated hardware optimizations can be made transparent to typical level 1 and 2 code.
Q:What are these levels you mention? 1,2 and 3?
A:
Transition to Level 3 code is the end of the CALLVEC [direct] influence.
To user code, Level 3 is the standard code environment that exists without CALLVEC implemented.
[either as hardware or emulation].
Level 2 code runs in memory space designated as such. The AEE is aware of this, even in emulation.
Code run in this mode can be standard RVI code and will work across all implementations.
Specialized code can also work with new opcodes and enhanced facilities, but will only work on similarly configured machines.
Level 1 code , by design, will have limitations imposed on it and although standard RVI code will run, some implementations will not allow certain behaviour. Just as correct LR/SC use is constrained, so level 1 code will be on any given implementation.
Q: What and where are these hardware assist modes?
A: Anywhere in executable memory can be designated level 1 or level 2 CALLVEC code.
Code that runs in either of these two levels runs under whatever hardware assists are available/enabled.
The hardware assists can be
The location the code is executed determines the CALLVEC acceleration features, and therefore any code executing in those areas is hardware assisted.
However, it is likely that implementations will use various methods to limit the access to these code areas, specifically some may limit such hardware acceleration to only be accessed from user-mode by CALLVEC. System modes will likely not be so constrained.
Q: What are these hardware assists?
A: The opportunity for such assists is open ended, CALLVEC is exceedingly extensible.
However, the envisioned initial assists are:
a) cache-line prefetch for
b) branch optimizations ; drop through code from level 1 to 2, and level 2 to 3
c) escape level 1 or 2 by branching to fixed location [typically level1 or level 2 zero entry]
c) cache and interrupt management optimizations ; level 1 code jamming.
d) special instructions for CALLVEC handling; level escape opcode rather than branch and drop through or branch zero entry.
e) special instructions for CALLVEC meta-execution; allow specifying register dynamically with prefix-instruction.
Q: what is [for each of a) through e) name hardware assist.
A: for each named hardware assist explain.
Q: are there limitations to the instructions used in CALLVEC.
A: Yes, in levels 1 and 2. . But what is typical
Q: Is CALLVEC itself interruptible:
A: Yes, level 1 and level 2 execution
Q: Is CALLVEC callable within CALLVEC?
A: Yes. But it may have limitations.
a) Level 1 is anticipated to be jammed into the instruction queue to be processes while other backgroud activities occur such as cache line load of level 2 and 3. So although saving ra and t0 to other temps is possible it makes those temps unavailable for the next CALLVEC, and the nested CALLVEC must restore ra and t0 before return to level 1, so interrupts will correctly configure restart, so the constraints on level 1 are formidable in a short code sequence.
Q: How performant is CALLVEC when not emulated?
A: When fully assisted, CALLVEC will be as performant as in-line code.
CALLVEC frequently asked questions
In that CALLVEC is new, question asked even once is relatively frequent. So here goes with some asked so far:
Q1) Why has CALLVEC been called "The Swiss Army Knife Of Instructions"?
A1) Because I thought it was an apt description.
Q2) Why was the instruction called CALLVEC?
A2) Because TSAKOI was too hard for me to pronounce. And because its primary use is expected to be a VECtored CALL; VECCALL was ignored as ambiguous; too hard to spell and pronounce. The vector calling allows for the Application Execution Environment to tailor the instruction to specific hardware.
Q3) WHAT DOES IT LOOK LIKE (instruction format).
A3) The final instruction format has not been determined yet, but its logical structure is < OPCODE>.
Q4) Where is CALLVEC used. A4) CALL VEC should always be used in a call context. The instruction always writes t0 [ this may be refined to another
Q) HOW DOES IT WORK (What does it do) A) Minimally, the hardware implemented CALLVEC: a) stores the instruction info into t0 [when emulated it stores the instruction word] b) it formats the instruction code format into a 17bit unsigned immediate into t0 c) it conditionally stores the return address into ra [depending upon immediate value] d) if ra was stored it conditionally ra
Q: Is that all? A: No, standard hardware optimizations can be made that because they are in "library routines" are transparent to the application code. Further, some of the more sophisticated hardware optimizations can be made transparent to typical level 1 and 2 code.
Q:What are these levels you mention? 1,2 and 3? A: Transition to Level 3 code is the end of the CALLVEC [direct] influence. To user code, Level 3 is the standard code environment that exists without CALLVEC implemented. [either as hardware or emulation].
Level 2 code runs in memory space designated as such. The AEE is aware of this, even in emulation. Code run in this mode can be standard RVI code and will work across all implementations. Specialized code can also work with new opcodes and enhanced facilities, but will only work on similarly configured machines.
Level 1 code , by design, will have limitations imposed on it and although standard RVI code will run, some implementations will not allow certain behaviour. Just as correct LR/SC use is constrained, so level 1 code will be on any given implementation.
Q: What and where are these hardware assist modes? A: Anywhere in executable memory can be designated level 1 or level 2 CALLVEC code. Code that runs in either of these two levels runs under whatever hardware assists are available/enabled. The hardware assists can be The location the code is executed determines the CALLVEC acceleration features, and therefore any code executing in those areas is hardware assisted. However, it is likely that implementations will use various methods to limit the access to these code areas, specifically some may limit such hardware acceleration to only be accessed from user-mode by CALLVEC. System modes will likely not be so constrained.
Q: What are these hardware assists? A: The opportunity for such assists is open ended, CALLVEC is exceedingly extensible. However, the envisioned initial assists are: a) cache-line prefetch for b) branch optimizations ; drop through code from level 1 to 2, and level 2 to 3 c) escape level 1 or 2 by branching to fixed location [typically level1 or level 2 zero entry] c) cache and interrupt management optimizations ; level 1 code jamming. d) special instructions for CALLVEC handling; level escape opcode rather than branch and drop through or branch zero entry. e) special instructions for CALLVEC meta-execution; allow specifying register dynamically with prefix-instruction.
Q: what is [for each of a) through e) name hardware assist. A: for each named hardware assist explain.
Q: are there limitations to the instructions used in CALLVEC. A: Yes, in levels 1 and 2. . But what is typical
Q: Is CALLVEC itself interruptible: A: Yes, level 1 and level 2 execution Q: Is CALLVEC callable within CALLVEC? A: Yes. But it may have limitations.
a) Level 1 is anticipated to be jammed into the instruction queue to be processes while other backgroud activities occur such as cache line load of level 2 and 3. So although saving ra and t0 to other temps is possible it makes those temps unavailable for the next CALLVEC, and the nested CALLVEC must restore ra and t0 before return to level 1, so interrupts will correctly configure restart, so the constraints on level 1 are formidable in a short code sequence.
Q: How performant is CALLVEC when not emulated? A: When fully assisted, CALLVEC will be as performant as in-line code.