> There are no dynamic link libraries (DLLs) or shared objects. Instead, there is only one type of function libraries that can be used for both static and dynamic linking. Only the part of the library that is actually used is loaded and linked. The library code is kept contiguous with the main program code in almost all cases. An executable file can be re-linked to update a function library or to adapt the program to a particular hardware configuration, operating system, or user interface framework.

So compiled code is forward compatible with new CPUs with longer vector registers, but it's not forward compatible with new libraries?

I find it a bit sad that people put so much effort into designing new ISAs that have nifty features, but then they make them so different from current ISAs that they basically can't run currently existing software.

This is Agner Fog pet architecture. It has zero chances of ever being implemented. At best is to be considered a wishlist from a well known assembly programmer.

It's only the beginning: https://github.com/ForwardCom

I thought same about Moxie, a wishlist architecture from a compiler developer. Then, hardware implementation of Moxie happened.

VHDL counts.

Also I don't see how something like libraries linking has anything to do with an ISA, which is mostly an OS implementation detail, AFAIU

Linking is always a largely a function of the ISA, because it is about taking partially finished chunks of code and glueing them together. In the case of dynamic libraries part of that has to do with the OS, more of it has to do with the instructions you have. Do you have segment registers, PC relative jumps or loads? How far do the instruction encoding allow, do you need things like branch islands, or TOCs, etc.

Sure, but why should an ISA dictate whether libraries are static or dynamic, unless they are planning to intentionally sabotage relative jumps or something similar?

The x86 and x64 ISAs allow both, but impose a significant performance penalty on dynamic linking.

I can see the appeal of an ISA which allows dynamic linking at no extra cost, so you’d never need to decide.

I completely agree. I was just responding that linking is intimately related to the ISA, which is relevant since the FowardCom info states that it does not support dynamic linking and instead all objects are instead relinkable (in the same way static linkers work). If you design an ISA with that mindset it is quite easy to omit instructions necessary to do efficient dynamic linking.

On a vaguely educated guess, it’s related to the lack of an MMU.

Selected Excerpts (with my comments):

"o An instruction can do multiple things, but only if it fits into the pipeline system. There is no need for microcode."

No microcode? Sign me up!

"o The ForwardCom design is scalable to support small embedded systems as well as large supercomputers and vector processors without losing binary compatibility."

Unbelievably forward-thinking!

"o The instruction set is fully orthogonal."

Aesthetically and mathematically pleasing!

"o Array loops are implemented in a new flexible way that automatically uses the maximum vector length supported by the microprocessor in all but the last iteration of a loop. The last iteration automatically uses a vector length that fits the remaining number of elements. No extra code is needed to deal with remaining data and special cases. There is no need to compile the code separately for different microprocessors with different vector lengths."

Utterly brilliant! Genius level intelligence!

Well, what do you expect? Agner Fog is a LEGEND in the assembly language community...

I've only skimmed it, but it smells a lot like Khaled Omar's "IPv10" draft: https://tools.ietf.org/html/draft-omar-ipv10-11.

How so? This is an ISA description, while the other document is for an IP protocol.