forwardcom forum

Some ForwardCom instructions are available in a short form using format template C. Template C has one register field, 16 bits of immediate data, and no operand size field. This will fit an instruction like for example int r1 += 1000 I am in doubt whether the integer size should be 32 bits or 64 bit...

Functions that receive a pointer can check if it is aligned. Functions like memcpy do that. But it is unrealistic to require that all functions have multiple paths for aligned and unaligned pointers. In most situations you can require that pointers be aligned according to the data size. Alignment of...

In most cases, the compiler will know whether memory is aligned or not. Standard functions like memcpy are checking whether the pointers are aligned before it decides which method is optimal. Shifting data to make it aligned can be done in software. This may be inconvenient for the programmer, but i...

Thank you Hubert for the explanation. It is a relevant discussion how caching can be made simpler. The ForwardCom design may have restrictions on alignment. Unaligned memory accesses could be split into two, or simply not allowed. The memcpy library function would need to shift data if source and de...

When I google for "shared virtual address model" I get something with CPU and GPU sharing the same virtual addresses, but still with fixed-size pages. I think there is little need for a GPU when the CPU has long vectors. But address translation after the cache may be a very good idea. I wo...

Thank you for the reference. I am not an expert in graphics processing, but I think that ForwardCom is well suited for adding graphics processing instructions. The fundamental data types and elementary instructions proposed by Pixlica are available in ForwardCom. ForwardCom has the further advantage...

Hubert Lamontagne, I am not sure you would want to have a a large graphics coprocessor. I would prefer to have a multicore ForwardCom processor with large vectors rather than a smaller ForwardCom processor connected to a graphics coprocessor using a different instruction set.

I prefer to have separate instructions for input and output, and a separate address space for in/out instead of memory mapped in/out. The reasons are: All memory addresses are relative and position-independent, while input/output addresses are usually absolute addresses. Code and data memory has a 6...

The push and pop instructions can write or read a sequence of registers with increment or decrement of the stack pointer or an arbitrary pointer register. It will typically take one clock cycle for each register plus an extra clock cycle in the end for updating the pointer. Support for these instruc...

Sebastian, I am not sure I understand your idea. Why do you think memory protection is critical for the speed, but address translation is not?

You may have to emulate fixed size page tables to run Linux etc. Or you may want to invent something new. ForwardCom can make memory blocks that are executable but not readable to make a true Harvard architecture, and memory blocks that are readable but not executable for security reasons. It can al...

A TLB lookup may take 1-2 clock cycles. A TLB miss costs many clock cycles. The chip area used for the TLB could be used for making a larger data cache or code cache instead. You can't have unlimited chip area without slowing down everything.

The x86 instruction set has many complex instructions with multiple output registers and multiple µops. Such complex instructions are implemented as microcode in both Intel and AMD processors. They are quite slow because the normal pipeline flow is interrupted while code is being fetched from a micr...

Regarding multi-register instructions: We should not have too many such instructions, because they are complicated to implement in the decoder. I have thought about instructions for zeroing many registers or clearing many vector registers. If you need a multi-register move, you could probably use a ...

The decision has been made now. I have removed the tiny instructions and updated all documentation and tools according to this change. New push and pop instructions are added. This change allowed me to get rid of a lot of complexity.

This is version 1.10.

There are many things that could possibly stall the pipeline: Read and write to the same address, or the CPU is unable to check whether memory addresses are overlapping. No vacant write buffer Cache misses No vacant register read port No vacant result bus An instruction is waiting for an operand fro...

Thank you for your responses. The problem I am trying to tackle is if some stage in the pipeline is stalled for whatever reason, it has to stop all preceding stages in the pipeline immediately. Kulaskos idea of a buffer between each stage would work, but it would require a lot of extra flip flops an...

I am thinking about how to coordinate the processing between the different stages in the pipeline. I want to know if I am doing the right thing or if there is a better way of doing this. Here is my idea: Each stage in the pipeline is a module with the following inputs and outputs: stall_in: Tells th...

I think it was you who advised me four years ago to avoid multi-output instructions. Now that I have started to work with a soft core I can see that you were right. It is good to reduce the number of register write ports and result buses. But splitting an instruction into multiple µops appears to be...

Thanks for the link. The x86-64 ISA has thousands of instructions. In fact, my x86 disassembler has a table of 2029 instructions. It is miraculous that Intel and AMD have actually managed to put all this on a single silicon chip and still get a good performance, but it is obviously not an optimal de...

At present, ForwardCom has four different instruction sizes. Most instructions use a single 32-bit code word. Instructions that need extra bits for constants, extra registers, extra option bits, etc. can use two or three 32-bit words. There is also a tiny instruction format. Two tiny instructions ca...

I have written in the specifications that it is recommended to have two separate stacks - a call stack for return addresses, and a data stack for local data. This was for security reasons to prevent buffer overflow attacks. Now I have found another advantage of separate stacks. While making the inst...

I have started to make a softcore for an FPGA (Artix 7). In this early stage, I am using only on-chip RAM so I don't need 64 bit addresses. But integer registers should probably be 64 bits anyway for the sake of compatibility. I guess it will be configurable so that you can choose floating point sup...

Maybe I should be more clear about local heap and global heap. The local heap is owned and managed by the program. The global heap belongs to the OS. A well-behaved program will ask the OS to allocate a big chunk of memory from the global heap and use it for its local heap. If the program has linked...

Yes, that would certainly be useful. Especially if the OS can know in advance whether a new process or a new thread needs the extra resources, so that it wouldn't have to jump to another core in case a thread has been started in a core that doesn't fit its needs.