If you want a "high-level" computer that can easily run high-level languages you can try building a stack machine. Check out the old LISP machines from the eairly 80s.
High level and fast for the time with some of the most interesting compiler design work.
Some other possible crazy ideas:
* Write instructions for forcing a read/write of memory into L1 cache
Allow me to tell the CPU to keep a chunk of memory im L1 for the lifetime of my program. I'll save you the transistors for figuring this out on the chip and it'll be easy to implement in a compiler. This is stuff that was done back in the NES and gameboy days (although by hand) with hi and lowmem.
* Put an easily interfaced FPGA on the die. Get rid of the stupid "one-size-fits-all" vectorization hardware we have today. We can just write our own vectorizations ourselves in the compiler level. Just make a big enough FPGA and we'll do all the math as fast as we want and in the parallelization we want.
This removes a very specific job oriented bit of transistors and allows it to be used for pretty much any problem that's complex enough to warrent attempting to use vectorization. One use of a combination of these ideas is writing an image filtering algorithm. It's a program that loops through the rows of my image, runs the "L1 cache" instruction from earlier, then passes it to my FPGA code which applies some complex filter, then writes it back to memory and continues. With traditional systems you'd be limited to 128 wide segments but I can presumably configure my FPGA segment to read the entire block of cache I want to load into and write back to it all as fast as possible.
This is an extremely hard thing to build but on-die FPGAs would change the face of computing. When they get big enough, who needs GPUs?
* Make core-shared fully atomic (large) registers for extremely fast but crude IPC
This is how most high level languages operate so I'd imagine this could definetly be made use of.
* Make the idea of a Core to Core MPI via interrupts and allow them to be configurally "synchronious" (page the program out until handled)
This allows the idea of calling a function on an object running in parallel with "this" object and it will be returned when this function is returned.
These are really crazy ideas. If I had inifnite money, time, and resources I probably couldn't pull something this "out there" off. I think the on-die FPGA is possible but impossible to get right. Most features on a modern processor that take up space are a conbination of functions that could all be done on an FPGA rather then wasting transistors on that specific function.
In a server do I really need 10 million transistors on my CPU for H264 decoding? Replace that with cache and a live-reprogrammable FPGA and we can do that all in software when and if we need it.
> keep a chunk of memory im L1 for the lifetime of my program
That is essentially what a scratchpad does. However, context switching is an issue, because the OS now has to maintain an even larger chunk of data in addition to the registers.
That should be handled at the OS level and the processor should provide facilities to directly store/page a program into a long term memory. The more the hardware can facilitate the lie that our program is living "forever" in ram the better. I have a feeling that we could also easily just add some memory chips into the computer board to just act as a super fast in-hardware swapfile to wait for things to be paged into memory then into disk.
The L1 cache should be configurable for the entier existance of a program and I'm pretty sure we'd see a lot less paging/pagefaults then.
How far away from your function is $some_global_variable? It doesn't matter if we can force the machine to always keep some_global_variable in cache.
But in short, it would definetly end up being like you say: people skrewing over other people, if there weren't other facilities in place to keep it safe and fast. It's a job for someone smarter then I.
The MIT Lisp Machine was basically a RISC architecture with an extra instruction to do multi-way switch, it ran an interpreter for the higher-level Lisp instruction set on top of this.
High level and fast for the time with some of the most interesting compiler design work.
Some other possible crazy ideas:
Allow me to tell the CPU to keep a chunk of memory im L1 for the lifetime of my program. I'll save you the transistors for figuring this out on the chip and it'll be easy to implement in a compiler. This is stuff that was done back in the NES and gameboy days (although by hand) with hi and lowmem. This removes a very specific job oriented bit of transistors and allows it to be used for pretty much any problem that's complex enough to warrent attempting to use vectorization. One use of a combination of these ideas is writing an image filtering algorithm. It's a program that loops through the rows of my image, runs the "L1 cache" instruction from earlier, then passes it to my FPGA code which applies some complex filter, then writes it back to memory and continues. With traditional systems you'd be limited to 128 wide segments but I can presumably configure my FPGA segment to read the entire block of cache I want to load into and write back to it all as fast as possible.This is an extremely hard thing to build but on-die FPGAs would change the face of computing. When they get big enough, who needs GPUs?
This is how most high level languages operate so I'd imagine this could definetly be made use of. This allows the idea of calling a function on an object running in parallel with "this" object and it will be returned when this function is returned.These are really crazy ideas. If I had inifnite money, time, and resources I probably couldn't pull something this "out there" off. I think the on-die FPGA is possible but impossible to get right. Most features on a modern processor that take up space are a conbination of functions that could all be done on an FPGA rather then wasting transistors on that specific function.
In a server do I really need 10 million transistors on my CPU for H264 decoding? Replace that with cache and a live-reprogrammable FPGA and we can do that all in software when and if we need it.