Source code changes for Forwardcom compatibility

[JoeDuarte]

Hi Agner – What sorts of changes will developers need to make to the source code of C and C++ programs in order to compile to a Forwardcom target, if any?

Joe

[agner]

A C++ compiler for ForwardCom is definitely on my wish list. It might be implemented as a back-end to Clang or Gcc.

Standard C and C++ programs should compile without problems as long as they don't rely on platform-specific features such as inline assembly or intrinsic functions.

Certain things work differently in ForwardCom that programmers may consider:

• Everything should be position-independent. Initialized pointer tables are position-dependent on most platforms. The compiler will insert a piece of initialization code that converts relative pointers to absoluter pointers at program startup if the C code specifies initialized absolute pointers. The programmer can make the code more efficient and safe by specifying read-only relative pointers. Some C++ compilers support relative pointers, using the __based keyword. The ForwardCom compiler should have a way of specifying relative function pointers and relative data pointers. (The compiler will always use relative pointers for implicit pointer tables such as switch statements and virtual function tables).
• Each thread should preferably have its own private memory space. Most other platforms allow different threads to access each other's memory.
• ForwardCom has a built-in event-handler system that the programmer can utilize.
• Error messages should preferably be implemented as events. This allows the system to report error messages in a way that is appropriate for the chosen user interface framework.
• System calls are platform specific, of course. A system call in ForwardCall must specify explicitly what memory block the system function can access if it needs to input or output a block of memory.
• Device drivers have limited and carefully controlled access rights.
• Program installation must use a standardized procedure.
• Loading a dynamic link library at runtime is possible, but it is preferred to link the library into the executable file before running it. There is a re-link tool for this purpose. Plug-ins can use this.

[JoeDuarte]

Certain things work differently in ForwardCom that programmers may consider:

• Everything should be position-independent. Initialized pointer tables are position-dependent on most platforms. The compiler will insert a piece of initialization code that converts relative pointers to absoluter pointers at program startup if the C code specifies initialized absolute pointers.

This will be interesting for programming languages like Go, which does not support ASLR on non-Linux platforms:

• https://insanitybit.github.io/2016/12/2 ... ory-safety

• https://rain-1.github.io/golang-aslr.html

I wonder what it would take to make Golang compatible with ForwardCom. It's a fast-growing, popular language, especially for networking. Rust and D might present interesting issues as well.

More broadly, I highly recommend computer science Professor John Regehr's essay Discovering New Instructions (https://blog.regehr.org/archives/669). Some key passages:

Sometimes I wonder what instruction sets are supposed to look like. That is, what instructions would there be if computers were redesigned by smart people who understood our fabrication capabilities and who knew what we wanted to accomplish using computers, but who didn’t care about backwards compatibility and who haven’t seen our architectures? We can get little glimpses into that world by looking at network processors, DSPs, GPUs, ISA extensions like SSE4 and NEON, extensible processors like Tensilica’s, and others. But still, these are too rooted in the past.

...So now we have a collection of giant dataflow graphs: one for each execution of each program that we’re interested in. Our goal is to design an instruction set that can compute these dataflow graphs. Trivially, this can be done by partitioning the graphs into very small units of computation corresponding to a RISC instruction set. But that ISA is boring and won’t show any performance wins. To do better we’ll use a search-based strategy to find subgraphs that:

• occur a large number of times across the collection of dataflow graphs — these are operations that are executed frequently by our workloads

• contain a lot of parallelism — making them good candidates for hardware acceleration

• contain a lot of internal symmetry — supporting SIMD-style execution

• have a small number of dynamic inputs and outputs

• rely on a small number of constants

• do not contain dependency chains that are too long — we don’t want to create instructions that are too slow

I think this can be done; none of these properties seems particularly difficult to test for. The major problem necessitating cleverness will be the huge size of the dataflow graphs. We’ll end up with a list of candidate instructions ranked by some fitness function, such as performance or code density. We can build as many of these into our new ISA as we have hardware budget for.

Would this method discover saturating arithmetic instructions when applied to signal processing codes? Would it find clever ways to optimize bounds checks and exception handling in high-level programming programming languages? It’s possible (though I’d be super disappointed) that the new machines are just incidental variations on existing RISC and CISC designs. If this happened, I would suspect that we had failed to abstract away a sufficient number of processor artifacts.

[JoeDuarte]

Agner, Have you given much thought to the changes needed to the C and C++ standard libraries. Would the musl C library be the best choice for ForwardCom initially, given that it's focused on statically linking? musl has a clean and standards-based compiler.

A C++ compiler for ForwardCom is definitely on my wish list. It might be implemented as a back-end to Clang or Gcc.

Standard C and C++ programs should compile without problems as long as they don't rely on platform-specific features such as inline assembly or intrinsic functions.

Certain things work differently in ForwardCom that programmers may consider:

• Everything should be position-independent. Initialized pointer tables are position-dependent on most platforms. The compiler will insert a piece of initialization code that converts relative pointers to absoluter pointers at program startup if the C code specifies initialized absolute pointers. The programmer can make the code more efficient and safe by specifying read-only relative pointers. Some C++ compilers support relative pointers, using the __based keyword. The ForwardCom compiler should have a way of specifying relative function pointers and relative data pointers. (The compiler will always use relative pointers for implicit pointer tables such as switch statements and virtual function tables).
• Each thread should preferably have its own private memory space. Most other platforms allow different threads to access each other's memory.
• ForwardCom has a built-in event-handler system that the programmer can utilize.
• Error messages should preferably be implemented as events. This allows the system to report error messages in a way that is appropriate for the chosen user interface framework.
• System calls are platform specific, of course. A system call in ForwardCall must specify explicitly what memory block the system function can access if it needs to input or output a block of memory.
• Device drivers have limited and carefully controlled access rights.
• Program installation must use a standardized procedure.
• Loading a dynamic link library at runtime is possible, but it is preferred to link the library into the executable file before running it. There is a re-link tool for this purpose. Plug-ins can use this.

[agner]

Would the musl C library be the best choice for ForwardCom initially ... ?

Yes, musl looks useful. I intend to write the most common library functions in ForwardCom assembly, the rest might use C code from musl.

[HubertLamontagne]

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 top to swap in win32 equivalents when needed). It all relies on shared objects in memory being accesses across threads, using mutexes to protect against race conditions. If you don't have this, you'll never see a port of Firefox or Unreal (or possibly even just Linux), because it multiplies the amount of effort required for the port by 100 - you end up having to hunt down every single shared memory object and replace it by some message passing mechanism since there's no way to abstract it away, and you're undoing 1000's of hours of bug-testing and bug-fixing the old way and you're opening a huge Pandora's box of potential new bugs.