There exist a vast array of prominent bitcode formats, each suited for their specific task:

• LLVM IR:

  This format is build around a XML like binary streams model, designed to be used as a common compiler target across a multitude of Architectures and languages.

• JVM bytecode:

  Java compile target, mainly; increasingly reused as a larger target in that ecosystem.

• Khronos Spir-V:

  Shader language target, graphics hardware abstraction.

• Web Assembly:

  Built as a target to better integrate ecosystems and existing code within the browser context.

• Specialized: (Ex. Lua and Python Bytecodes):

  Interpreters generally execute bytecode during execution whether, explicitly or not.

The hardware/ISA ecosystem is equally split, particularly amoung ARM, i386/x86, x86_64, Microchip/Atmel and now Risc-V. Fragmentation also exists in the computer graphics industry, which in many ways has outpaced CPU growth in recent times. Hardware Acceleration Layer/API design is primary split between Khronos and Microsoft, but now apple and Google are joining in; Even in the case of the two leading providers, backwards compatibility has proven to be a difficult problem, leading to increased segmentation and overhead.

I only see these problems getting worse in the future with the current state of traditional Moore's Law, increasing use of accelerators and FPGAs, IoT proliferation, diverse memory types and caching mechanisms, hyperscaling, etc...

In the past, segmentation has been forsean and in the case of character set localization, avoided. This is why the Unicode Consortium was Established, independent of any single company/organization. The Unicode Consortium has managed to standardize over 100,000 character encodings to date and this is virtually universal.

Theoretically I see no reason why this cannot be accomplished in the bitcode/turing realm.

https://www.quora.com/unanswered/Why-is-there-no-extensive-standards-organization-for-instruction-set-architectures-ISA-and-bitcodes-as-there-is-in-the-case-of-Unicode-1

In Response to Community:

• @Gilles Unicode acts as a super-set of its predecessor, ASCII; it conforms to UTF-8, UTF-16 and UTF-32 standards. Modern microprocessors are no strangers to expanding type codes in their instruction decoding pipelines. Any machine can emulate larger types than its baseline and architecture level support for this is not uncommon.

There exist a vast array of prominent bitcode formats, each suited for their specific task:

• LLVM IR:

  This format is build around a XML like binary streams model, designed to be used as a common compiler target across a multitude of Architectures and languages.

• JVM bytecode:

  Java compile target, mainly; increasingly reused as a larger target in that ecosystem.

• Khronos Spir-V:

  Shader language target, graphics hardware abstraction.

• Web Assembly:

  Built as a target to better integrate ecosystems and existing code within the browser context.

• Specialized: (Ex. Lua and Python Bytecodes):

  Interpreters generally execute bytecode during execution whether, explicitly or not.

The hardware/ISA ecosystem is equally split, particularly amoung ARM, i386/x86, x86_64, Microchip/Atmel and now Risc-V. Fragmentation also exists in the computer graphics industry, which in many ways has outpaced CPU growth in recent times. Hardware Acceleration Layer/API design is primary split between Khronos and Microsoft, but now apple and Google are joining in; Even in the case of the two leading providers, backwards compatibility has proven to be a difficult problem, leading to increased segmentation and overhead.

I only see these problems getting worse in the future with the current state of traditional Moore's Law, increasing use of accelerators and FPGAs, IoT proliferation, diverse memory types and caching mechanisms, hyperscaling, etc...

In the past, segmentation has been forsean and in the case of character set localization, avoided. This is why the Unicode Consortium was Established, independent of any single company/organization. The Unicode Consortium has managed to standardize over 100,000 character encodings to date and this is virtually universal.

Theoretically I see no reason why this cannot be accomplished in the bitcode/turing realm.

https://www.quora.com/unanswered/Why-is-there-no-extensive-standards-organization-for-instruction-set-architectures-ISA-and-bitcodes-as-there-is-in-the-case-of-Unicode-1

In Response to Community:

• @Gilles Unicode acts as a super-set of its predecessor, ASCII; it conforms to UTF-8, UTF-16 and UTF-32 standards. Modern microprocessors are no strangers to expanding type codes in their instruction decoding pipelines. Any machine can emulate larger types than its baseline and architecture level support for this is not uncommon.

Reference:

• VLIW Architecture
• Unicode Consortium

There exist a vast array of prominent bitcode formats, each suited for their specific task:

• LLVM IR:

  This format is build around a XML like binary streams model, designed to be used as a common compiler target across a multitude of Architectures and languages.

• JVM bytecode:

  Java compile target, mainly; increasingly reused as a larger target in that ecosystem.

• Khronos Spir-V:

  Shader language target, graphics hardware abstraction.

• Web Assembly:

  Built as a target to better integrate ecosystems and existing code within the browser context.

• Specialized: (Ex. Lua and Python Bytecodes):

  Interpreters generally execute bytecode during execution whether, explicitly or not.

The hardware/ISA ecosystem is equally split, particularly amoung ARM, i386/x86, x86_64, Microchip/Atmel and now Risc-V. Fragmentation also exists in the computer graphics industry, which in many ways has outpaced CPU growth in recent times. Hardware Acceleration Layer/API design is primary split between Khronos and Microsoft, but now apple and Google are joining in; Even in the case of the two leading providers, backwards compatibility has proven to be a difficult problem, leading to increased segmentation and overhead.

I only see these problems getting worse in the future with the current state of traditional Moore's Law, increasing use of accelerators and FPGAs, IoT proliferation, diverse memory types and caching mechanisms, hyperscaling, etc...

In the past, segmentation has been forsean and in the case of character set localization, avoided. This is why the Unicode Consortium was Established, independent of any single company/organization. The Unicode Consortium has managed to standardize over 100,000 character encodings to date and this is virtually universal.

Theoretically I see no reason why this cannot be accomplished in the bitcode/turing realm.

https://www.quora.com/unanswered/Why-is-there-no-extensive-standards-organization-for-instruction-set-architectures-ISA-and-bitcodes-as-there-is-in-the-case-of-Unicode-1

In Response to Community:

• @Gilles Unicode acts as a super-set of its predecessor, ASCII; it conforms to UTF-8, UTF-16 and UTF-32 standards. Modern microprocessors are no strangers to expanding type codes in their instruction decoding pipelines.

There exist a vast array of prominent bitcode formats, each suited for their specific task:

• LLVM IR:

  This format is build around a XML like binary streams model, designed to be used as a common compiler target across a multitude of Architectures and languages.

• JVM bytecode:

  Java compile target, mainly; increasingly reused as a larger target in that ecosystem.

• Khronos Spir-V:

  Shader language target, graphics hardware abstraction.

• Web Assembly:

  Built as a target to better integrate ecosystems and existing code within the browser context.

• Specialized: (Ex. Lua and Python Bytecodes):

  Interpreters generally execute bytecode during execution whether, explicitly or not.

The hardware/ISA ecosystem is equally split, particularly amoung ARM, i386/x86, x86_64, Microchip/Atmel and now Risc-V. Fragmentation also exists in the computer graphics industry, which in many ways has outpaced CPU growth in recent times. Hardware Acceleration Layer/API design is primary split between Khronos and Microsoft, but now apple and Google are joining in; Even in the case of the two leading providers, backwards compatibility has proven to be a difficult problem, leading to increased segmentation and overhead.

I only see these problems getting worse in the future with the current state of traditional Moore's Law, increasing use of accelerators and FPGAs, IoT proliferation, diverse memory types and caching mechanisms, hyperscaling, etc...

In the past, segmentation has been forsean and in the case of character set localization, avoided. This is why the Unicode Consortium was Established, independent of any single company/organization. The Unicode Consortium has managed to standardize over 100,000 character encodings to date and this is virtually universal.

Theoretically I see no reason why this cannot be accomplished in the bitcode/turing realm.

https://www.quora.com/unanswered/Why-is-there-no-extensive-standards-organization-for-instruction-set-architectures-ISA-and-bitcodes-as-there-is-in-the-case-of-Unicode-1

In Response to Community:

• @Gilles Unicode acts as a super-set of its predecessor, ASCII; it conforms to UTF-8, UTF-16 and UTF-32 standards. Modern microprocessors are no strangers to expanding type codes in their instruction decoding pipelines. Any machine can emulate larger types than its baseline and architecture level support for this is not uncommon.