forwardcom forum

This looks very exciting. I am looking forward to see your results.

Your multicore sieve of Eratosthenes would be very expensive to implement in hardware because the data cache needs to combine single bits from each core.

ForwardCom has many instructions for bit manipulation including instructions to extract, insert, or move bit fields with an arbitrary number of bits in each element. This allows efficient packing of information. If you have many booleans then it is most efficient to make bit vectors that can handle ...

I am somewhat skeptical too. CHERI is proposing a very costly solution to a problem that can be solved in other ways. I haven't looked too deeply into CHERI, but as I understand it, it requires a lot of changes in both hardware and software: The hardware ISA must have an extra set of special 128-bit...

does that mean there is no BTB cost for forward never-taken branches?

On some processors, yes.

Isn't this a case where forwardcom would do much better than traditional cpus? Because the call stack is expressed explicitly, it is the same as the return prediction stack. So after you install a new call stack, you maybe pipeline stall, but then start start predicting returns correctly from it. Y...

Thank you for trying to find weak points in my system. I think that nonlocal returns may be implemented more efficiently as a sequence of normal returns. 1. Why? Why is it more efficient to return multiple times than just once? Because it doesn't mess up the return prediction. A non-local return wil...

I think that nonlocal returns may be implemented more efficiently as a sequence of normal returns. It is possible to have multiple data stacks on ForwardCom. The compiler could use a register or an extra stack or a particular stack space to keep track of the nesting level. Error handling can also be...

You are right that stack unwinding requires privileged instructions. Stack unwinding takes place in the following cases: Exception trapping (try/catch) in object oriented languages Debugging longjmp in C Exception trapping and debugging require privileged access anyway. A program that has a large nu...

The more fragmented the memory becomes, the more complicated becomes the access: In simple cases where there are few processes running and plenty of vacant RAM, you don't need any address translation. All you need is a small memory map with a few variable-size entries. This memory map can stay on-ch...

Thank you for your interesting comments. kyle-forward wrote: Many parsers and similar algorithms use recursion True. This even includes the parser in the ForwardCom assembler. But the recursion level is not very deep. How are things like ASRL going to be done? The security problems that "Addres...

Thanks for the link. If you want to mix half-size (16 bits) with word size (32-bits) instructions then all addresses would need 16-bit granularity. Adding one bit at the bottom means removing one bit at the top. In other words, the length you can jump with an 8-bit address offset is halved. Furtherm...

Thanks for the proposal. This has been proposed before. It would be difficult to find space for the extra bits which might be better used for other purposes, and it will make linkers, loaders, and other tools more complicated if they have to split 32-bit and 64-bit constants into non-contiguous fiel...

Thanks for the idea. Your example can be implemented in C as if (1 << x & 0b1001001000){} Both Gcc and Clang compilers are actually using this optimization. This can be implemented in ForwardCom assembly: int r1 = 0b1001001000 int r2 = [x] bit_test(r1,r2), jump_true Whatever The bit_test will be...

I have been working hard on developing a softcore implementation of ForwardCom, and I am now proud to publish the first version on Github. Features: Implemented on Nexys A7 FPGA board with Xilinx Artix 7 100T FPGA Coded in System Verilog with an open license Everything is made from scratch. No borro...

Thank you for your comment. I was not aware of MRISC32. It looks like we have got some of the same ideas. ForwardCom allows instructions to be up to three 32-bit words. This makes it possible to overcome the problem of cramming a lot of information into a single code word, that most RISC designs suf...

Now I have tried to synthesize it in an FPGA. The solution with a complete truth table is using 18% more slices and 40% more LUTs than the bitwise_logic circuit I described above. The truth table implementation is using less resources than I expected because the FPGA has efficient ways of implementi...

Not 100%. Hubert has fertilized it with valuable insight in hardware design :-)

I have an idea for a multi-purpose 3-input bitwise boolean instruction. This instruction can implement all functions of the type RESULT = (A AND/OR B) AND/OR/XOR C with optional inversion on all inputs and outputs. It can also do A XOR B XOR C and bit selection: A AND B OR NOT A AND C . The latter c...

Hubert, my main motivation for making load+alu instructions is to do more work per instruction = higher throughput. The x86 instruction set is quite efficient despite a terribly complicated decode process, exactly because it does more work per instruction. This is also reducing the register load. An...

Power consumption is also an issue. 32 bit integers use less power. My soft core can run faster when 64-bit integers are not implemented. While writing C++, I eventually switched to size_t size_t is unsigned, so it would not fit the short version loop instructions. The corresponding signed type in C...

Most integer instructions are available in both 8, 16, 32, and 64 bits versions. The question is only which one to prioritize for short instructions (single code word). The forthcoming version (1.11) will have both 32 and 64 bit short versions of some instructions. Most branch and loop instructions ...

The solution that Hubert proposes is already possible with the present design. ForwardCom supports a separate read-only data section addressed relative to IP. An addressing mode with [IP + offset + scaled index] is also supported. I don't remember if we have discussed this before, but it is certainl...

Thank you for your suggestion. A problem with your proposal is that jumps are costly, especially if the pipeline is long, because they interrupt the prefetching and decoding of instructions. Another problem is that the table needs multiple copies if it is accessed from multiple points in the code. I...

The x86 instruction set introduced prefixes long ago. Today, there is a lot of different prefixes that are 1, 2, 3, and 4 bytes long. There is no limit to how many prefixes an x86 instruction can have as long as the complete instruction is no more than 15 bytes long. This is a nightmare to decode. T...