Intel Publishes "X86-S" Specification For 64-bit Only Architecture

erek

erek

[H]F Junkie
Joined
Dec 19, 2005
Messages
10,874
New architectures are cool

“Under this proposal, those wanting to run legacy operating systems or 32-bit x86 software would have to rely on virtualization.

Those interested can see Intel's documentation around the proposed 64-bit only architecture X86-S via Intel.com.

It's still likely some years away before seeing this possible x86S/X86-S architecture for going 64-bit only but very interesting to see Intel beginning these moves for doing away with the legacy modes.”

Source: https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
 
Though are they going for Itanium round 2?

IA-64 architecture now known as Intel Itanium Architecture failure is an instant reminder

https://en.wikipedia.org/wiki/IA-64
https://en.wikipedia.org/wiki/Itanium

1684603275892.jpeg
 
I was all in favor of ditching 32bit operating systems and felt that should have happened a long time ago (2010?) but ditching backwards compatibility with 32bit code seems kind of shitty.

The ability to natively execute code dating back to the 16bit 8086 is part of the benefit of the PC platform.

If you are going to break legacy compatibility, why not just ditch x86 all together and go ARM, MIPS or RISC-V?
 
I don't know how much of anything this is really going to save, but ok I guess. The smp init stuff and the 5-layer page table transition bits are nice, but there's no reason they couldn't add that without taking away the other stuff.
 
Last edited:
“The X86-S proposal is indeed interesting and demonstrates Intel's vision for a more streamlined, 64-bit only approach to its x86 architecture. It's important to note that if implemented, this would mark a significant shift for Intel and for the computing industry as a whole.

Intel's proposal would simplify the architecture by eliminating legacy support and the complexities of the current x86-64 design. Removing support for 32-bit software, ring 1 and 2, and 16-bit addressing can help in reducing the chip's complexity, potentially leading to better performance, power efficiency, and a reduced attack surface for security vulnerabilities.

The proposed shift to 5-level paging could potentially enable the addressing of vastly larger amounts of memory than current 4-level paging, which could be beneficial in high-performance and data-intensive workloads.

However, there are some challenges associated with this shift. One of the most significant is that legacy 32-bit applications would no longer be able to run natively on the new architecture. As stated, this would necessitate the use of virtualization or emulation for running older software. This could pose compatibility issues and may impact performance, depending on the efficiency of the virtualization/emulation layer.

Intel's decision to solicit industry feedback is a smart move as this is a considerable change that could impact many stakeholders, including software developers, computer manufacturers, and end users.

Although the proposed changes are substantial, they appear to be in line with the general industry trend towards 64-bit architectures. This movement has been underway for some years now, with 64-bit processors becoming the standard in many computing environments, especially in the server and high-performance computing (HPC) markets.

It's also important to note that Intel's new direction with the X86-S is, as of now, still a proposal. It might take several years before this architecture is implemented, if it is decided to be pursued after receiving feedback from the industry. The development of such a new architectural design, as well as establishing a broad software ecosystem support, is a complex and time-consuming process.

This proposal from Intel signifies an important potential shift in the industry and it will be interesting to follow the progress and see the industry's response to the X86-S specification.”

“The comparison between Intel's proposed X86-S architecture and the previous IA-64 Itanium architecture is a valid one. Both represent significant shifts from the then-existing norms, with a focus on moving away from legacy support and towards a more forward-looking, 64-bit only architecture.

However, there are some important differences to consider. The most significant of these is the industry context. When Itanium was released, the software ecosystem was heavily reliant on 32-bit architectures. The transition to 64-bit was not as mature as it is today, and the Itanium architecture was not backward compatible with the x86 instruction set, which resulted in significant compatibility issues.

The Itanium's Explicitly Parallel Instruction Computing (EPIC) design was also a shift from the industry norm. It placed more responsibility on the compiler for performance optimization, a task which compilers at the time were not particularly well equipped to handle. This led to performance issues which further hindered the adoption of Itanium.

With the proposed X86-S architecture, the situation is different. The computing industry is far more mature in its transition to 64-bit architectures now. Many applications have already migrated to 64-bit, and operating systems have largely moved in this direction as well. Additionally, virtualization technologies have matured greatly, offering a viable solution for running legacy applications.

Of course, it's important to remember that any major architectural shift like this comes with challenges. Backward compatibility and the ability to run legacy applications are important considerations. And, as with Itanium, there is the risk of alienating developers, users, and manufacturers if the transition is not managed well.

However, if Intel can learn from the past and manage the transition carefully, it's possible that X86-S could provide the benefits of a more simplified and efficient architecture without repeating the difficulties encountered with Itanium.”
 
erek said:
“The X86-S proposal is indeed interesting and demonstrates Intel's vision for a more streamlined, 64-bit only approach to its x86 architecture. It's important to note that if implemented, this would mark a significant shift for Intel and for the computing industry as a whole.

Intel's proposal would simplify the architecture by eliminating legacy support and the complexities of the current x86-64 design. Removing support for 32-bit software, ring 1 and 2, and 16-bit addressing can help in reducing the chip's complexity, potentially leading to better performance, power efficiency, and a reduced attack surface for security vulnerabilities.

The proposed shift to 5-level paging could potentially enable the addressing of vastly larger amounts of memory than current 4-level paging, which could be beneficial in high-performance and data-intensive workloads.

However, there are some challenges associated with this shift. One of the most significant is that legacy 32-bit applications would no longer be able to run natively on the new architecture. As stated, this would necessitate the use of virtualization or emulation for running older software. This could pose compatibility issues and may impact performance, depending on the efficiency of the virtualization/emulation layer.

Intel's decision to solicit industry feedback is a smart move as this is a considerable change that could impact many stakeholders, including software developers, computer manufacturers, and end users.

Although the proposed changes are substantial, they appear to be in line with the general industry trend towards 64-bit architectures. This movement has been underway for some years now, with 64-bit processors becoming the standard in many computing environments, especially in the server and high-performance computing (HPC) markets.

It's also important to note that Intel's new direction with the X86-S is, as of now, still a proposal. It might take several years before this architecture is implemented, if it is decided to be pursued after receiving feedback from the industry. The development of such a new architectural design, as well as establishing a broad software ecosystem support, is a complex and time-consuming process.

This proposal from Intel signifies an important potential shift in the industry and it will be interesting to follow the progress and see the industry's response to the X86-S specification.”

“The comparison between Intel's proposed X86-S architecture and the previous IA-64 Itanium architecture is a valid one. Both represent significant shifts from the then-existing norms, with a focus on moving away from legacy support and towards a more forward-looking, 64-bit only architecture.

However, there are some important differences to consider. The most significant of these is the industry context. When Itanium was released, the software ecosystem was heavily reliant on 32-bit architectures. The transition to 64-bit was not as mature as it is today, and the Itanium architecture was not backward compatible with the x86 instruction set, which resulted in significant compatibility issues.

The Itanium's Explicitly Parallel Instruction Computing (EPIC) design was also a shift from the industry norm. It placed more responsibility on the compiler for performance optimization, a task which compilers at the time were not particularly well equipped to handle. This led to performance issues which further hindered the adoption of Itanium.

With the proposed X86-S architecture, the situation is different. The computing industry is far more mature in its transition to 64-bit architectures now. Many applications have already migrated to 64-bit, and operating systems have largely moved in this direction as well. Additionally, virtualization technologies have matured greatly, offering a viable solution for running legacy applications.

Of course, it's important to remember that any major architectural shift like this comes with challenges. Backward compatibility and the ability to run legacy applications are important considerations. And, as with Itanium, there is the risk of alienating developers, users, and manufacturers if the transition is not managed well.

However, if Intel can learn from the past and manage the transition carefully, it's possible that X86-S could provide the benefits of a more simplified and efficient architecture without repeating the difficulties encountered with Itanium.”
Click to expand...

It's a fair point if you think about it

I can already throw 10 native ~4.5Ghz CPU cores and GPU passthrough at a VM for any 32bit app/game, more in the future, far different situation
 
erek said:
“The X86-S proposal is indeed interesting and demonstrates Intel's vision for a more streamlined, 64-bit only approach to its x86 architecture. It's important to note that if implemented, this would mark a significant shift for Intel and for the computing industry as a whole.

Intel's proposal would simplify the architecture by eliminating legacy support and the complexities of the current x86-64 design. Removing support for 32-bit software, ring 1 and 2, and 16-bit addressing can help in reducing the chip's complexity, potentially leading to better performance, power efficiency, and a reduced attack surface for security vulnerabilities.

The proposed shift to 5-level paging could potentially enable the addressing of vastly larger amounts of memory than current 4-level paging, which could be beneficial in high-performance and data-intensive workloads.

However, there are some challenges associated with this shift. One of the most significant is that legacy 32-bit applications would no longer be able to run natively on the new architecture. As stated, this would necessitate the use of virtualization or emulation for running older software. This could pose compatibility issues and may impact performance, depending on the efficiency of the virtualization/emulation layer.

Intel's decision to solicit industry feedback is a smart move as this is a considerable change that could impact many stakeholders, including software developers, computer manufacturers, and end users.

Although the proposed changes are substantial, they appear to be in line with the general industry trend towards 64-bit architectures. This movement has been underway for some years now, with 64-bit processors becoming the standard in many computing environments, especially in the server and high-performance computing (HPC) markets.

It's also important to note that Intel's new direction with the X86-S is, as of now, still a proposal. It might take several years before this architecture is implemented, if it is decided to be pursued after receiving feedback from the industry. The development of such a new architectural design, as well as establishing a broad software ecosystem support, is a complex and time-consuming process.

This proposal from Intel signifies an important potential shift in the industry and it will be interesting to follow the progress and see the industry's response to the X86-S specification.”

“The comparison between Intel's proposed X86-S architecture and the previous IA-64 Itanium architecture is a valid one. Both represent significant shifts from the then-existing norms, with a focus on moving away from legacy support and towards a more forward-looking, 64-bit only architecture.

However, there are some important differences to consider. The most significant of these is the industry context. When Itanium was released, the software ecosystem was heavily reliant on 32-bit architectures. The transition to 64-bit was not as mature as it is today, and the Itanium architecture was not backward compatible with the x86 instruction set, which resulted in significant compatibility issues.

The Itanium's Explicitly Parallel Instruction Computing (EPIC) design was also a shift from the industry norm. It placed more responsibility on the compiler for performance optimization, a task which compilers at the time were not particularly well equipped to handle. This led to performance issues which further hindered the adoption of Itanium.

With the proposed X86-S architecture, the situation is different. The computing industry is far more mature in its transition to 64-bit architectures now. Many applications have already migrated to 64-bit, and operating systems have largely moved in this direction as well. Additionally, virtualization technologies have matured greatly, offering a viable solution for running legacy applications.

Of course, it's important to remember that any major architectural shift like this comes with challenges. Backward compatibility and the ability to run legacy applications are important considerations. And, as with Itanium, there is the risk of alienating developers, users, and manufacturers if the transition is not managed well.

However, if Intel can learn from the past and manage the transition carefully, it's possible that X86-S could provide the benefits of a more simplified and efficient architecture without repeating the difficulties encountered with Itanium.”
Click to expand...
There is also a big gain here for data centers that can't be understated, Intel by 2025 will have lost more potential data center sales to ARM than they have from AMD and this could be a very big deal for Intel in that space. If data centers are showing that they are willing to adopt an entirely new architecture and abandon backward compatibility for the sake of increased power/performance metrics then it demonstrates a very large need for a shift in what they are offering to that space. This very well could be that offering.
 
erek said:
Of course, it's important to remember that any major architectural shift like this comes with challenges. Backward compatibility and the ability to run legacy applications are important considerations. And, as with Itanium, there is the risk of alienating developers, users, and manufacturers if the transition is not managed well.
Click to expand...
^^THIS^^

Technological challenges usually represent the opportunity for learning how to begin moving forward and leaving the legacy stuff in the review view mirror...something that should have happened with computer hardware & software etc a L.O.N.G. time ago....and the resistance to making this change is one of the biggest reasons why things are the way they are now...

Hell, even though most windows installations are called "64bit", when you look through the code base, there are STILL many, many parts written in 32 bit strings :D

So if M$ would make a stronger push on this process, I feel certain that other sw developers would follow them sooner rather than later.

As for VM's are concerned, as already noted, that situation is way better now than in past years, as is the availability of cheap ram & storage to accommodate & manage their use...

So to borrow a past phrase from the US ARMY:

"Lets make 64bit computing all it can be", hehehe :)
 
DooKey said:
It's time to move on from legacy 32-bit code. Hopefully the market agrees.
Click to expand...
Speaking personally I am in a spot where if they offered 8 or so E cores for legacy compatibility and gave me 8-16 of these 'S' cores I would be perfectly content and I struggle to find anything I am currently doing that would not function.
 
Lakados said:
Speaking personally I am in a spot where if they offered 8 or so E cores for legacy compatibility and gave me 8-16 of these 'S' cores I would be perfectly content and I struggle to find anything I am currently doing that would not function.
Click to expand...
Nah, sometimes you just need to quickly pull that Band-Aid off the wound.
 
Lakados said:
There is also a big gain here for data centers that can't be understated, Intel by 2025 will have lost more potential data center sales to ARM than they have from AMD and this could be a very big deal for Intel in that space. If data centers are showing that they are willing to adopt an entirely new architecture and abandon backward compatibility for the sake of increased power/performance metrics then it demonstrates a very large need for a shift in what they are offering to that space. This very well could be that offering.
Click to expand...

This is probably fine for data centers; almost everybody is running 64-bit only Linux, so NBD. Outliers running unix are fine too. Windows server probably isn't bad either. But the gains just aren't going to be very big. Keeping ring 1 and 2 and the I/O stuff in ring 3 isn't free, but it's not that expensive. Addressing modes aren't that expensive either. It will certainly decrease the size of their microcode, but I don't think microcode is a big consumer of die space (although, who knows, maybe it is).
 
toast0 said:
This is probably fine for data centers; almost everybody is running 64-bit only Linux, so NBD. Outliers running unix are fine too. Windows server probably isn't bad either. But the gains just aren't going to be very big. Keeping ring 1 and 2 and the I/O stuff in ring 3 isn't free, but it's not that expensive. Addressing modes aren't that expensive either. It will certainly decrease the size of their microcode, but I don't think microcode is a big consumer of die space (although, who knows, maybe it is).
Click to expand...

I think Intel is just at that point of eeking out what they can where they can
 
This is really a big move. Good to see Intel is proactively moving forward instead of sitting still on its own legacy.
The legacy 32-bit support is actually a great protection for Intel. There are so many ancient applications there at the server side. You never know what may happen if drop the legacy instruction support. This additional cost and risk kind of preventing the migration from x86 to ARM.
 
DooKey said:
Nah, sometimes you just need to quickly pull that Band-Aid off the wound.
Click to expand...
I was thinking but what if I wanted to play something in my steam list from pre 2016. The E cores are more than enough to handle that. Those aren’t really heavily threaded either so really 4 would probably be sufficient.
 
Lakados said:
I was thinking but what if I wanted to play something in my steam list from pre 2016. The E cores are more than enough to handle that. Those aren’t really heavily threaded either so really 4 would probably be sufficient.
Click to expand...
That's true. However, aren't they talking data center stuff and not consumer stuff? Not sure.
 
DooKey said:
That's true. However, aren't they talking data center stuff and not consumer stuff? Not sure.
Click to expand...
Who knows at work I have way way way too much legacy running on my server stacks and making that work on anything right now is a major PITA. I wouldn’t dream of making that change there any time soon.
But building a dedicated all E core HCI stack for those could be interesting. Even just 2 in a simple redundancy configuration would be more than sufficient to meet the computing needs and if I went all solid state the IO shouldn’t be a problem… move that to its own thing and let the rest function on its own stack… that could save me some headaches perhaps.

Note:
I say E cores because for compatibility I have to disable Hyper-Treading or SMT for some of them (yeah some of the software is that old) so the E cores don’t have it so it’s not an issue.
 
staknhalo said:
What 32bit application would be more demanding than a game
Click to expand...
I guess that depends. Some games hardly hit the CPU and others hammer it.

My comments are more towards data center. I'm not sure if 64-bit is a bonus for gaming/consumer or not.

Anyway, I'm for progress and not stagnation.
 
DooKey said:
I guess that depends. Some games hardly hit the CPU and others hammer it.

My comments are more towards data center. I'm not sure if 64-bit is a bonus for gaming/consumer or not.

Anyway, I'm for progress and not stagnation.
Click to expand...

I wasn't talking consumer either, just literally a game as a 32bit application, what's really gonna be more demanding or test your entire overall system more than that - like I said if you need just compute we have more than enough cores to throw at a 32 bit app in a VM, - same with storage, RAM, GPU passthrough - if you're thinking 'still not enough' then you should be thinking 'should have been a 64bit app long ago'

If you can play a game you can run your app 👍
 
Absalom said:
It already did. It came out in 1999 and was called SSE.

Unless you mean 128-bit addressing, which is dumb and uncessesary considering 64-bit addressing takes us all the way up to exabytes of addressable memory.
Click to expand...
IIRC we only use 48-bits for addresses today anyways.
 
Zarathustra[H] said:
I was all in favor of ditching 32bit operating systems and felt that should have happened a long time ago (2010?) but ditching backwards compatibility with 32bit code seems kind of shitty.

The ability to natively execute code dating back to the 16bit 8086 is part of the benefit of the PC platform.

If you are going to break legacy compatibility, why not just ditch x86 all together and go ARM, MIPS or RISC-V?
Click to expand...

ARM is just jumping from one frying pan into another... plus ARM was going to take over "any day now" for what, like at least a decade or more?

RISC-V is the only ISA that I think has a real future but it's still a bit away although approaching rapidly, the performance improvements on RISC-V every year are quite impressive, they've gone from "look it can blink an LED!" a couple years ago, to chips that can load up linux with a GUI and play youtube videos (just barely - but still)
 
longblock454 said:
When does 128bit x86 debut?
Click to expand...
I’ve been working on that for a few days now


“In this scenario, you want a 128-bit wide memory cell which can be addressed with a 128-bit address. Here's how you could adjust the VHDL code to reflect this:

```vhdl
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity memory_2 is
port (
Clk: in std_logic;
ReadWrite: in std_logic; -- '0' for Read, '1' for Write
Address: in std_logic_vector(127 downto 0);
Data_in: in std_logic_vector(127 downto 0); -- Assuming 128-bit data
Data_out: out std_logic_vector(127 downto 0)
);
end entity memory_2;

architecture behavioral of memory_2 is
type memory_array is array (0 to 2**128-1) of std_logic_vector(127 downto 0);
signal memory: memory_array;
begin
process (Clk)
begin
if rising_edge(Clk) then
if ReadWrite = '1' then
-- Write operation
memory(to_integer(unsigned(Address))) <= Data_in;
else
-- Read operation
Data_out <= memory(to_integer(unsigned(Address)));
end if;
end if;
end process;
end architecture behavioral;
```

And the equivalent SystemVerilog code:

```systemverilog
module memory_2 (
input Clk,
input ReadWrite,
input [127:0] Address,
input [127:0] Data_in,
output logic [127:0] Data_out
);

// Assuming FlipFlops are positive edge-triggered D flip-flops
// Create a memory array of 2^128 128-bit wide memory cells
reg [127:0] memory [0:2**128-1];

always_ff @(posedge Clk) begin
if (ReadWrite) begin
// Write operation: write Data_in to the selected memory location
memory[Address] <= Data_in;
end
else begin
// Read operation: read data from the selected memory location to Data_out
Data_out <= memory[Address];
end
end
endmodule
```

Again, as previously mentioned, such an implementation is purely theoretical. It's not practically possible to allocate a memory array of size 2^128, even more so when each memory cell is 128 bits wide. Even in a simulation environment, you'd need an astronomical amount of memory to support this.”


“
A direct implementation of such a huge memory in hardware isn't feasible due to current technology limitations. However, for the sake of theoretical exploration, we could consider the concept of "virtual memory" or "sparse memory".

**Virtual Memory**

Virtual memory is a memory management technique where secondary memory (like a hard disk or SSD) can be used as if it were a part of the main memory (RAM). Operating Systems use this technique to execute processes that may not entirely fit into the available main memory.

**Sparse Memory**

Sparse memory implementation can be used when the majority of the memory space is unused. This is a data structure technique where only the locations with meaningful data are stored, and a default value is returned for all other locations.

In the context of hardware design and VHDL/SystemVerilog, here's a theoretical approach to a sparse memory implementation:

1. **Memory Management Unit**: Implement a Memory Management Unit (MMU) that handles the address translation from this 128-bit addressable memory to actual physical memory, similar to how virtual memory is managed in an Operating System.

2. **Page Table**: Implement a "Page Table" or similar structure that keeps track of which addresses are in use and where the data for each address is stored. The page table can be stored in physical memory and may need to be paged itself.

3. **Address Translation**: When an address is accessed, the MMU translates the address using the page table. If the address is in use, the MMU fetches the data from physical memory. If the address is not in use, the MMU returns a default value (like all zeros).

4. **Memory Allocation**: When writing to an address for the first time, the MMU allocates a memory cell for it and updates the page table.

5. **Memory Recycling**: Implement a memory recycling strategy to manage physical memory usage. For example, when a memory cell's data is the same as the default value, it can be de-allocated and removed from the page table.

This approach would allow the system to behave as if it had a 128-bit addressable memory, while only using a fraction of the physical memory for the actually used addresses. However, this would still need a substantial amount of memory and processing power to manage the MMU and page table.

Please note that this is just a theoretical approach. Implementing this in hardware, especially in FPGA or ASIC, would come with its own set of challenges and performance implications.

Additionally, it's worth noting that these techniques would only be practical if the memory usage is sparse. If the design requires frequent access to a large number of unique addresses, the memory and computational requirements could still become prohibitive.”
 
FLECOM said:
ARM is just jumping from one frying pan into another... plus ARM was going to take over "any day now" for what, like at least a decade or more?

RISC-V is the only ISA that I think has a real future but it's still a bit away although approaching rapidly, the performance improvements on RISC-V every year are quite impressive, they've gone from "look it can blink an LED!" a couple years ago, to chips that can load up linux with a GUI and play youtube videos (just barely - but still)
Click to expand...
It's also very unclear at this point that the ISA makes that much difference in chip speed/efficiency. It isn't that is has NO impact but the RISC heads have been carrying on about how bad CISC is and how it makes chips slow since the 80s... and yet here we are. The idea that if we just switched to new ISA X or Y chips would be so much faster really should be regarded as bogus. ARM, POWER, PPC, MIPS, SPARC, etc, etc none of these have been leaps and bounds better than X86 (or other CISC architectures like z). They aren't bad, they can work very well as ARM demonstrates, but it isn't a situation where ARM just dominates and those poor X86 chips are just screwed.

To me it makes sense Intel would stick with a compatible architecture even if removing legacy stuff because what would change get them?
 
DooKey said:
It's time to move on from legacy 32-bit code. Hopefully the market agrees.
Click to expand...
Um, why? There are virtually zero benefits for most code outside of certain scientific applications and various numerical analysis applications that need higher precision that can be had by migrating away from 32-bit. Truly, the only real NEED for larger-than-32-bit anything really revolves around memory addressing, as more and more applications are being designed as memory hogs. Video games in particular only really need large swaths of memory because of the ever larger imagery they use for their visuals. It's not the processing that even matters here, it's the memory address space to be able to shuffle around multiple gigabytes of bitmaps. Larger bit width ALUs won't give you any performance benefit for scenarios like this.

One of the side effects of moving to pure 64-bit code will also be a doubling of the binary size. Every single pointer and register op is now doubled in size. That will mean a need for more memory to do the same amount of work. It will also mean physically larger CPUs, again, with a doubling of the size of registers and the data paths to move those data words around.

I'm not saying 64-bit isn't without its merits at all, but for the vast majority of use cases 32-bit and hell even 16-bit is just fine and migrating to 64-bit won't bring any real performance improvements to applications. This is my take as a software developer.

My personal take on what Intel is proposing here: They absolutely hate being beholden to x86-64 because it's not theirs. They're also seeing the market buzzword shift to 64-bit due to ARM. After the last couple years of missteps, Intel is desperately trying to find its way to being THE name in computing technology again, so this is their stab at it. Not that what they're proposing is a bad thing at all. After all, look at what Apple has done.
 
longblock454 said:
As much of a joke my comment was, some day that will happen!
Click to expand...
i was seriously investigating it though


""Faking" enough conventional memory for synthesis tools, specifically in the context of a memory-intensive design like a 128-bit addressable memory space, might be possible with certain techniques, such as the aforementioned virtual memory or sparse memory methods. The fundamental idea here would be to provide an illusion of a larger memory space than is physically available.

However, keep in mind that synthesis tools are not designed to handle such vast amounts of memory, and it's not just a question of memory allocation. The tool must also generate a physical layout for the design, manage routing resources, perform timing analysis, etc.

In addition, "faking" memory doesn't help when the actual hardware comes into play. If the hardware doesn't actually have this massive amount of memory, it won't be able to function as expected, regardless of what the synthesis tool believed was available during design time. If the design truly requires a 128-bit addressable space, and especially if a significant part of this address space needs to be used, there is no getting around the requirement for an immense amount of physical memory.

If the actual usage of the 128-bit addressable memory is sparse, methods like memory paging, or other techniques used in managing virtual memory, might be used to create a workable solution. However, these would come with trade-offs in terms of complexity, speed, and perhaps other aspects of system performance.

Remember that as of my knowledge cutoff in September 2021, no practical implementation exists for a native 128-bit addressable memory system, even with techniques to "fake" or "virtualize" the memory. Theoretical discussions like this one are interesting and might point towards future directions for research and development, but current technology is not equipped to realize such a system."

"In principle, if we can develop a shim or interface that makes DNA-based memory behave like conventional memory from the perspective of the synthesis tool and other system components, then it might be possible to use DNA memory in this context.

However, it's important to realize that this interface would need to abstract away all the differences between DNA memory and conventional electronic memory, including the vastly different read/write speeds, lack of random access, and the need for special error checking and correction methods.

Additionally, to be transparent to synthesis tools and behave as a regular memory to other components of the digital system, this interface should also be capable of interacting in real time, which is currently challenging given the speed of operations with DNA.

Moreover, the interface will need to translate between electronic signals and biochemical operations, which is a non-trivial challenge. It would likely require some sort of hybrid system combining biological and silicon-based components.

Even if all these challenges could be overcome, there's still the issue of cost. As of my knowledge cutoff in 2021, the cost of reading and writing DNA was still quite high, making it less suitable for general-purpose computing.

In conclusion, while it's theoretically possible to devise such an interface, there are significant practical challenges to overcome.
 
Wat said:
I'd like to see native support for 128 bit floating point math.
Click to expand...
supposedly fixed point is faster

If you had dedicated hardware to perform fixed-point arithmetic, it would likely be faster than floating-point arithmetic for a couple of reasons:

  1. Simpler arithmetic operations: Fixed-point operations are less complex than floating-point operations. For instance, multiplication and division are more straightforward with fixed-point numbers.
  2. Lower resource requirements: Fixed-point units require fewer transistors than floating-point units, meaning that more of them can fit into the same space, and they consume less power. This could allow for higher parallelism, increasing the overall computational speed.
  3. No need for conversion: When using fixed-point arithmetic, you often don't need to convert between different representations, which could also save time.
--
"there are numerous techniques to optimize the use of fixed-point arithmetic and mitigate some of its limitations. Here are a few:

  1. Look-Up Tables (LUTs): As you've mentioned, LUTs can be very effective in optimizing certain calculations. You can store precomputed results of complex functions in memory and then simply look up the results when needed, instead of calculating them each time. However, this increases memory usage and may not be feasible for functions with a large input space. Moreover, LUTs are usually used to replace mathematical functions (like trigonometric functions), rather than to directly increase precision.
  2. Piecewise Linear Approximation: This technique can be used to approximate non-linear functions, which are typically costly to compute in fixed-point arithmetic. The idea is to split the function into several linear segments. Each segment can be evaluated with a simple multiplication and addition, reducing computational complexity.
  3. Scaling: To increase precision, you can scale your fixed-point numbers by a factor, effectively increasing the number of fractional bits. This can be useful when dealing with very small numbers. However, remember to rescale your results appropriately to avoid errors.
  4. Fraction saving: In some algorithms, instead of rounding off the fractional part after each step, we save it and add it to the next input. This is also a sort of error feedback which helps in increasing the precision of the fixed point operations.
  5. Multiple-Word Arithmetic: For operations requiring larger dynamic range and higher precision, you can use multiple fixed-point words together. For example, double-precision or quad-precision arithmetic.
Remember, each of these techniques comes with trade-offs in terms of complexity, speed, and resource usage. The best choice depends on the specific requirements of your application and the capabilities of your hardware.

In general, while these techniques can help, there's no getting around the fact that fixed-point arithmetic has inherent limitations compared to floating-point arithmetic, particularly in terms of dynamic range and precision. If your application requires handling very large/small numbers or needs very high precision, floating-point arithmetic might be more suitable, provided you have the necessary hardware resources."
 
Wat said:
I'd like to see native support for 128 bit floating point math.
Click to expand...
There's a trick to doing that using two 64-bit floats. Effectively you approximate with one float and use the other for storing the error.

Ironically within the past 10 years there's been more demand for lesser precision floating point hardware. GPUs have added 16-bit and even 8-bit float support. Mainly because they don't take up much space and you can pack a lot of them on a die. Neural networks don't need crazy high precision floats, but training LLMs requires tons of them.

128-bit floats are a nice idea, but not exactly in demand right now.
 
  • Like
Reactions: erek
like this
Absalom said:
There's a trick to doing that using two 64-bit floats. Effectively you approximate with one float and use the other for storing the error.

Ironically within the past 10 years there's been more demand for lesser precision floating point hardware. GPUs have added 16-bit and even 8-bit float support. Mainly because they don't take up much space and you can pack a lot of them on a die. Neural networks don't need crazy high precision floats, but training LLMs requires tons of them.

128-bit floats are a nice idea, but not exactly in demand right now.
Click to expand...
What about 128bit addressable memory space? Can the same analogous trick be applied
 
erek said:
What about 128bit addressable memory space? Can the same analogous trick be applied
Click to expand...
Addresses are best calculated using integer math. I don't see any way around that.

How would you address the value 3.68934881E+19? I made that arbitrary value up, but real values could look like that. You'd have to convert it back to an integer, then round to nearest power of 2. While functionally correct, it would require far more clock cycles than just simply binding the 128-bit address from two 64-bit integer registers.

The only case where it would make sense is if you had no ALU to do integer math. The only scenario I can think of is if NASA had a space probe billions of miles away with a now malfunctioning ALU. I wouldn't be surprised if NASA has done something creative like that.

Edit:

For those curious, here's a paper on doing high precision float calcs using conventional hardware:

https://link.springer.com/chapter/10.1007/11758501_34
 
Last edited:
  • Like
Reactions: erek
like this
dogDAbone said:
^^THIS^^

Technological challenges usually represent the opportunity for learning how to begin moving forward and leaving the legacy stuff in the review view mirror...something that should have happened with computer hardware & software etc a L.O.N.G. time ago....and the resistance to making this change is one of the biggest reasons why things are the way they are now...

Hell, even though most windows installations are called "64bit", when you look through the code base, there are STILL many, many parts written in 32 bit strings :D
Click to expand...
64 bit isn't inherently better nor faster than 32 bit. Sometimes the opposite.

I don't find the legacy support a crutch for Intel. If anything, it's what keeps them more relevant in a world with rising competition. The impact on their CPUs regarding complexity, size, or power consumption, is overblown.


SunnyD said:
I'm not saying 64-bit isn't without its merits at all, but for the vast majority of use cases 32-bit and hell even 16-bit is just fine and migrating to 64-bit won't bring any real performance improvements to applications. This is my take as a software developer.

My personal take on what Intel is proposing here: They absolutely hate being beholden to x86-64 because it's not theirs. They're also seeing the market buzzword shift to 64-bit due to ARM. After the last couple years of missteps, Intel is desperately trying to find its way to being THE name in computing technology again, so this is their stab at it. Not that what they're proposing is a bad thing at all. After all, look at what Apple has done.
Click to expand...
More likely than not.
 
You must log in or register to reply here.
Back
Top