Reply to post:

Linus Torvalds pulls pin, tosses in grenade: x86 won, forget about Arm in server CPUs, says Linux kernel supremo

StargateSg7

I've looked at over 100 different CPU/GPU/DSP architectures in 30 years+ of programming and what I DID is create one single CUSTOM VIRTUAL INSTRUCTION SET and compile all my C/C++, Pascal or Basic source code to that Virtual Instruction Set which includes ONLY the most basic CPU/GPU/DSP instructions and Bit-Widths (i.e. a Virtual RISC machine) and and then let my compiler's back-end cross-compile processor de-construct that virtual instruction set to whatever chip-specific or hardware accelerated instruction set my make file and compiler flags are set to, be they x86, ARM, MIPS, SuperSPARC, A12, 68000-series, 6502, Z80, SHARC, IBM Power7/8/9/10, DSP, MCU, MPU, FPU, GPU, ASIC, even a low-level cheap PIC!

This means by using ONE SINGLE make file, I can set my compiler output to ANY 8-bit, 16-bit, 32-bit, 64-bit and 128-bit CPU/GPU/DSP chip I want and my compilers AUTOMATICALLY optimize the Virtual RISC Instructions I output to very-processor-specific instruction sets. Since ALMOST ALL chips have the same TYPES of BASIC assembler instructions, I've been able to keep a library of simple, pre-defined and HIGHLY OPTIMIZED assembler sub-routines which substitute for my Virtual CPU/GPU/DSP instructions. Any larger bit-widths or media-specific instructions NOT available on the target system, get truncated/merged downwards to fit on an automated basis. I've been able to compile and run a TEXT-based "windowing" system on an 8-bit 6502 and a 16-bit 80286 using the SAME source code designed for our custom 128-bit GaAs chip because the cross-compiler automatically takes care of the limits of the destination processor and MAKES THINGS FIT into available RAM/DISK and CPU speed by changing graphics and windowing into lower resolutions, bit-depths and even text-mode if necessary! It even takes care of Flat mode and Segmented Memory, unusual file/disk access systems, real-mode vs Virtual mode switching, hard interrupt vs cooperative processing, IP V4/V6 local network and global communications, and other quirks of 1970's era to 2010's era common CPU/GPU/DSP chips!

The earliest Pascal and Fortran compilers used to do this. They originally output p-Code which was a virtualized instruction set which was then de-constructed into chip-specific assembler by the back-end compiler on an at-runtime basis, or as a final executable file depending upon your compiler flags. I do the same thing BUT I have highly optimized back-end assembler for over a 100 CPU/GPU/DSP chips which means my source code is FULLY multi-platform capable with high-end real and virtual memory management, virtualized desktops, communications, file and disk handling, windowing, graphics, database, toolbars and back-office objects.

As a New chipset comes along, I merely make a Textfile-based Lookup Table (LUT) which maps my virtual instruction set to the optimized and error-checked-and-error-trapped chip-specific assembler code. And since I only use a basic 150 virtual instructions specific to CLASSES OR TYPES of chips such as a general purpose single-to-multi-core CPU, a GPU or a DSP-only chip, it takes me barely a week to two to add the NEW processor to my cross-compiler which handles C/C++, Pascal and Basic as the front-end source code.

.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon