forwardcom forum

• 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 wrote: ↑2018-01-24, 7:03:24 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.

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

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

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.

agner wrote: ↑2018-01-24, 7:03:24 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.

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