forwardcom forum

It seems to me like the discussion in this thread derailed a bit. That said, I want to offer my opinion on the static vs dynamic linking debate before returning to topic. I did not find much about the benefits of dynamic linking. I did find the GNU people liking the lower amount of redundancy and to...

For my bachelor thesis, I examined the impact certain features present in ForwardCom have on processor performance. It's only a synthetic test using a self-built CPU simulator, but it demonstrates an actual performance merit ForwardCom could have for hardware implementations. As such, it also valida...

I recently stumbled upon this interesting, pretty old paper: https://dl.acm.org/doi/pdf/10.1145/1162690.1162694 In short, the paper proposes storing separate descriptors for instruction blocks. They replaced a branch target buffer with a cache for these descriptors, and the front-end of the processo...

I have been thinking on your question a bit. At this stage, there's only a few people working on the project, so there isn't much pressure to create a dedicated organization for it. However, especially the copyright part is an important argument. Having an organization owning the code would allow le...

Oh, I forgot one thing. D. No gather & scatter instructions Now these would probably be implemented by a state machine splitting them into individual loads and stores, they are not really needed when hand-coding assembly, and their efficiency gain is debatable. Even so, compilers love these inst...

These are my current thoughts: 1. Speculative memory read This would eliminate the need of padding space as in chapter 9.1 in the current specification. As far as I understood, the ForwardCom linker (and maybe also the assembler) currently allocates a static memory region between constants and code ...

After way too much time, I finally managed to release a ForwardCom-capable CPU simulator in usable condition. I will use it to examine ForwardCom features for a performance impact in my bachelor thesis. It can be found here, though binaries are not available yet: https://git.h3n.eu/gpcas/gpcas The C...

CHERI indeed requires a fair amount of changes, but as far as I have seen, it still looks reasonable. I want to comment on a few points you made in your last post: Most importantly, it can be implemented by extending the general purpose registers to 128 bit, instead of introducing another register s...

I recently stumbled upon the CHERI project because there is an ongoing effort inside the Rust language to change pointers in order to support its memory model. It can also be supported by other languages such as C/C++ by imposing some restrictions, with the ultimate goal of greatly enhancing memory ...

By random browsing, I just stumbled upon this paper on compressed RISC-V instructions: https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf I don't think any of the specific results are of too much interest for ForwardCom, but the data-driven methodology make me think. RISC-VC seems to be ...

I would be in favor of 64 bits, for the reason to have a clean "native" size that is also shared with pointers. While writing C++, I eventually switched to size_t as my default type for this very reason. I don't like to have an arbitrary type dependent on what some compiler thinks is right...

Forcing store operations to never be speculative simplifies a lot of these tasks (it kinda turns the cpu into a partially in-order CPU?) but I'm not sure I can come up with a kind of architecture that could do this without causing huge stalls... Assuming no other core is dependent on the data of a ...

This is meant as more of a general topic for people who wish to comment or inform themselves about using CPU cores (or a CPU ISA) as a GPU accelerator. If this can be done efficiently, ForwardCom should be a good fit for such a use case as it allows for very large vectors. A company called Pixilica ...

You could provide some fixed-function-hardware to some cores, accessed as an extension of the standard ForwardCom ISA. ForwardCom already has decode space reserved for extensions, there are also plans for adding an FPGA portion to each core. But in general, the viability and efficiency of a "Fo...

So I take it you are against adding an instruction for storing two independent (general purpose) registers?

As I was translating a program compiled to ARM assembly to ForwardCom, I realized that ARM can load and store two registers whereas ForwardCom can only do one register, apart from the push and pop instruction. They have additional restrictions such as registers needing to be next to each other (for ...

Is the logic for multi-register push and pop too specific to be shared? I thought that perhaps, the multi-register logic that already is needed because of this could be used as a more general multi-register instruction generator. That would enable multi-register instructions without much added compl...

As there already needs to be some logic for emitting multi-register push and pop instructions, wouldn't it make sense to add other multi-register instruction versions, for example for a move? To be honest, I didn't think much further than this up to now, but a multi-register move could certainly mak...

As I don't have any experience concerning multi-stage pipelines in HDLs, I can't really say if your proposal is a good way of doing it. Looking at it, it should work, I might have some concerns with timing/routing, as every stage has to be able to send a stall_out signal to a central module and rece...

I can't think of an application that needs a combined stack. I am however opposed to using implementation details that don't change functionality as an argument for such a requirement. Of course, the found advantages can be noted in the ForwardCom manual and security is still a valid argument. I am ...

Thank you for your replies. Having instructions that require multiple micro-ops doesn't necessarily mean you need microcode. You are right, I didn't think about that. I still have some difficulty dealing with this as it complicates the decoding stage. Presumably, decoders don't have a constant laten...

I'll use a load unit that emits two loads for now. A load size predictor would certainly make sense for more elaborate designs. The naive way of first loading the size and then loading the data could cause a fairly long instruction latency, but I will go with this for now for simplicity's sake. I fo...

I also agree with the idea of a heavily threaded in-order core with large vectors being a good fit for ForwardCom. Depending on the workload, one could even use the flexibility of variable size vectors and balance core count and vector size for an implementation. However, I disagree with the thought...

I'm actually interested in this as well. I would like to build a system with cpu cores with different vector length, a scheduler that is aware of that and "driver" to do graphics acceleration. I would even be happy with 2D acceleration only. It also would be especially interesting for hete...

I recently had some difficulty while planning a microcode-less CPU design based on ForwardCom. Specifically, I am having some trouble with the restore_cps instruction. The restore_cps instruction is used for efficiently loading a vector from memory. The vector is saved in a compressed image with var...