forwardcom forum

For the string operations: Code that deals with a a lot of strings is often very branchy and does complex addressing, even outside of string byte manipulations. This limits speed gains a lot. Loops in that kind of code often have stuff like if(rareErrorCondition) {fprintf(stderr, "Error\n"...

Yeah, forwardcom would definitely be targettable from a compiler at least for the integer part. Presumably you'd end up with the following register pools for the register allocator: - r0 and r8-r15: can be used for tiny instructions and don't overlap masks so they should be used preferentially - r1-...

Have you seen what STOKE can do? It doesn't address your specific cases, but it optimizes the hell out of code, which is why it's called a SuperOptimizing Compiler. I just took a look. It looks impressive for a research project. Though, from what I gather, it's geared towards optimizing numerical c...

I would say your real-world "sum-of-x86-ARM-MIPS-PPC-68k-SPARC-ALPHA-ITANIUM-PARISC-SUPERH-32/64bit-compiled-on-GCC/LLVM/MSVC/ICC" has already so different behaviors that you cannot expect much more than what C is providing. [...] I beg to differ. There's a wide range of behaviors that ar...

Incorrect. That is what run of the mill programmers think that C is, but they are wrong. C is what I described: A programming language for a highly abstract machine whose constructs are not representations of instructions in the machine ISA. Hence that “a + b” with “a” and “b” of type “int” should ...

Compilers can't generally figure out how to move calculations to a second thread - they can't track all the potential side effects. This applies not only to C++, but also pretty much all higher level languages like Java and Javascript and whatnot. But could compilers be made to have such abilities ...

Hubert, what happens if the second workload is performed on a separate core? For EPIC, I'd assume lots of cores. Compilers can't generally figure out how to move calculations to a second thread - they can't track all the potential side effects. This applies not only to C++, but also pretty much all...

By the way, the Itanium is looking sweeter than ever given its immunity to Meltdown and Spectre. I feel like the industry needs to move forward at faster clip. For Itanium, I'm going to say something controversial here: it's actually a worse architecture than x86 (!). Itanium's idea is that the com...

So the Cell just sort of faded away over time? It seemed like real innovation in hardware and ISAs, which is rare. The Cell hasn't faded away. Its major feature (multiple cores can be used for lots of throughput) has been applied to x86 and ARM, and 4+ core CPUs are now common. The major benefit is...

I disagree with the implicit premise of this article. C is not just abstracted assembly. It is not a convenient abstraction for the instructions of your machine. It is a programming language for a very abstract machine. When you write “a + b”, you are performing that operation in the abstract machi...

So I am wondering, is it possible to make a superscalar processor with no speculative execution at all? We can have speculative fetch, decode, and address calculation in connection with branch prediction, but stop speculating before the execute stage in the pipeline and before the out-of-order back...

Would forwardcom be fundamentally compatible with architectures like Rex Computing, which discards the traditional caching hierarchy in favor of a massive number of cores with 128 KB of scratchpad memory per core? http://rexcomputing.com/ That architecture reminds me a lot of the PS3's Cell process...

Casey Muratori has a talk that I think is interesting and probably a good idea for an angle for forwardcom to target:
The Thirty Million Line Problem
https://www.youtube.com/watch?time_cont ... ZRE7HIO3vk

Afaik, most multiplications in 64bit code are 32x32->32 (int * int), 32x32->64 (int * sizeof(X) for indexing), 32x64->64 (int * size_t) or 64x64 (size_t * size_t). 64x64->128 is very rare, except in code processing ultra-larger integers (like finding that 2^77232917 − 1 is a prime). And a lot of cod...

For multiplication, if you want to detect a wrap, there's really no other way than doing it full size and checking the top part of the result, regardless of it's done in software or hardware. It's going to be long in every case (electric delay) and the only thing changed by which instruction does it...

The fused Add-and-conditional-jump instructions you have already have are pretty heavy duty way to essentially generate a trapping instruction, no? All you have to do is jump to a trap.

I think the best approach is just to check between the old and the new value for the wraparound and branch if it happens. Sure, it's going to take you a few arithmetic operations to check everything out (1 or 2 if the operand is an immediate, 4~ish if it's a signed variable of unknown sign depending...

Looking at the specs, there's one feature that's going to generate tons of pipeline hardware complexity and that I'm 99% sure will never ever get used in any code: Mask bit #6 "Generate a trap if unsigned integer overflow" Mask bit #7 "Generate a trap if signed integer overflow" ...

It only really makes sense for financial applications, no?

1. Signed integer overflow: https://kristerw.blogspot.ca/2016/02/how-undefined-signed-overflow-enables.html explains why the do the "exploit" (aka exploit a flaw in the C/C++ specs that was left because of some archaic 36bit-honeywell and ibm-fault-on-overflow hardware) of assuming that in...

Kulasko : Looking at your pipeline, Load+ALU ops being scheduled twice (once in the Address scheduler going to the AGU, once in the Scheduler going to the ALUs) has the same effect as having a separate micro-OP for the load and the ALU part. This indeed solves the reason for having split micro-ops (...

Off the top of my head : Divide by 0 exceptions: There are two camps on this one... "Make it fail as hard as possible" and "Crashing the whole app does way more damage than the numerically crazy values it guards against". Generally it's the server backend people (where your datab...

I'm looking at the Forwardcom ops and trying to figure out what the pipeline of a typical implementation would look like... Here's what I have yet: Stage 1: Align The goal of this stage is to take the raw current and previous icache lines (presumably something like 16bytes~ each) and align individua...

One suggestion: - Have a native threading API for threads with private memory space - <pthreads.h> implements shared memory threading compatible with Linux and OSX all the other OS's. Rationale: There are tons and tons and tons of software built on specifically this (generally with a thin layer on t...

Anyhow, the most common customizations you see on CPUs are for making smaller embedded versions. The most common configurations you see in the wild: - 32bit, no MMU, no FPU, no SIMD: fast micro-controller. Truckloads of ARM and MIPS use this, such as STM32's which are taking over the hardware world....