Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
Discussion Groups | FPGA-CPU | Re: Bird Brained Idea (humour)
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Bird Brained Idea (humour) - rtfinch35 - Jan 5 16:42:00 2002
|
Homework question: Why is this a bad idea ? I was updateing the assembler for my current project and I realized I had allowed for register direct calls (eg. "call r5") by mistake. Now I'm thinking this is not such a bad idea. There is no reason why this instruction can't be encoded. The actual instruction to be executed could be stored in a register, and with a little hack to the cpu, fed directly into the instruction stream. So it would appear to operate just like a call instruction. It could be useful in some circumstances. For instance, the raster op instruction in a graphics program could be stored in a reg. and the draw function could do a register direct call to execute the raster op without actually calling a function. It could also be used to implement case sensitive / insensitive string routines using a single function. It could be used to avoid writing self modifying code in some circumstances. A really dumb idea (why?) --> Extending the idea further, immediate mode calls could also be allowed where the instruction to execute could be encoded as an immediate operand in the call instruction. Rob http://www.birdcomputer.ca |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Bird Brained Idea (humour) - Eric Smith - Jan 5 17:06:00 2002
|
> I was updateing the assembler for my current project and I realized I > had allowed for register direct calls (eg. "call r5") by mistake. Now > I'm thinking this is not such a bad idea. There is no reason why this > instruction can't be encoded. It's not an inherently bad idea, but I don't think it's all that generally useful, either. There are some specialized cases where it is a bit helpful, but there are other ways to handle those. The drawback is that you need an additional data path from the register file to the instruction register or instruction decoder. If you don't want to stall the pipeline, you also need an additional read port in the register file. Some machines (e.g., PDP-10) have addresses for the general registers, and it is possible to execute code from them. This was useful back in the days when registers were much faster than memory AND there was no cache. And it was more useful than a way to execute a single instruction, although the PDP-10 did had an XCT instruction for that. But having the registers in the main memory address space makes it harder to do some optimization to the implementation. For instance, you don't know whether there's a conflict when reading a register if a preceding store instruction hasn't finished evaluating its effective address yet, because its destination may be that register. |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Bird Brained Idea (humour) - browsasaurus - Jan 5 19:35:00 2002
|
--- In fpga-cpu@y..., "rtfinch35" <robfinch@s...> wrote: > Homework question: Why is this a bad idea ? > > I was updateing the assembler for my current project and I realized > I had allowed for register direct calls (eg. "call r5") by mistake. > Now I'm thinking this is not such a bad idea. There is no reason > why this instruction can't be encoded. I would suggest there are two issues to consider: (1) How can the same operation be performed using existing instructions? (2) Do you want to make it a permanent feature of your ISA? With respect to the first point, the obvious alternatives would be self-modifying code or a fast subroutine call. In the case of self-modifying code you may have a cache cost (invalidation) but if you are talking about a situation where you patch in the instruction and then use it many times, this cost is tiny. If you are using an ISA with a jump and link style calling convention, then the cost of calling a subroutine in assembly is pretty low (one cycle for the jump and one for the return). Your new call function is going to cost one cycle for the call itself. So if you are only calling the function a few times, the calling cost difference (one versus two cycles) is negligable. If you are using it lots of times, then patching code may actually be faster since the calling cost drops to zero (though with the potential cache invalidation cost up front). I personally think the second point is probably more interesting, especially with respect to an FGPA based processor. While it might not require a lot of effort to add the support to your current core, what about future cores? I guess I think of a good ISA of having value all of its own. Once you manage to get an assembler and compiler ported to an ISA, that seems like an investment you want to protect by using the same ISA in future projects if possible. If you add something that has limited value now, adjust your tools to use it, then redesign your core later on and find the feature causes you problems and have to remove it (from the core and your tools), have you gained anything? If you view it in terms of commercial microprocessors, it comes down to the fact that it is easy to add features to an ISA and really difficult to remove them in future generations. Now since you are doing this as a personal project, you can really do anything you want (there is no right nor wrong). However, you asked for feedback :). Greg Schaefer |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Bird Brained Idea (humour) - Author Unknown - Jan 6 15:48:00 2002
|
Hello. My humble guesses follows... > Homework question: Why is this a bad idea ? > > I was updateing the assembler for my current project and I realized I had > allowed for register direct calls (eg. "call r5") by mistake. Now I'm > thinking this is not such a bad idea. There is no reason why this > instruction can't be encoded. [......] It probably will stall your pipeline, and it could ruin any techniques as execution trace cache. The problem is worst if the preceeding instruction modifies that register. And of course, you would have to manage it as a conditional jump, as it could be - or could not be - a real jump instruction at any moment. You won't know it until actually executing (remember, you can be forced to wait until register modification). > A really dumb idea (why?) --> Extending the idea further, immediate > mode calls could also be allowed where the instruction to execute > could be encoded as an immediate operand in the call instruction. Of course, just remove the "call" word in the source code XDD Best regards, Rob. ## ## # ## # # # # # # # # # # # # # # # # # # # # # # ## # # # # # # ## # # ## ##### # # # # # # # # # # # # # # # ## # # # # # # # # # # # # # # # # # # ## # # ### # # # # # # # # # # # # ## # # # # # # # # # # # ## # ## # # # # # # # # # ## # # # # ## # # # # # # # # #### # # # # # # # # # # # # # # # # # # # # # # # # # # # # ## ## ### ## ## ## ## #### |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )