News AMD EPYC Genoa-X Weilds 1.3 GB of L3 Cache, 96 Cores

[Admin]

AMD announced that its Genoa-X processors are now shipping with up to 96 cores and 1.1 GB of L3 cache.

AMD EPYC Genoa-X Weilds 1.3 GB of L3 Cache, 96 Cores : Read more

 

[abufrejoval]

I'm tempted to ask "but does it run Windows 95?"

I am trying to think which OS variants I was actually operating when main memory was around 1GB.

I believe Windows 95 and its ilk actually topped out at 512MB, so Windows NT 3.51 or 4.0, perhaps 2000 seem likely, I held on to AMD K2/KIII very long before I went with various AMD64 until the Q6600 thrashed them. But since AMD64 meant bridging the 4GB barrier of 32-bit, that must have been later.

Anyhow, at this point you'd want a RAM-less mode supported by the chip, if only for kicks, which allows you to actually run a fully functional 64-Bit OS only from cache...

 

[derekullo]

I got me a 1.3 gigabytes of cache
I never feed trolls and I don't read bash
Installed a fiber line in my house
Always at my PC, double-clickin' on my mizouse



...forgive me

 

[hotaru.hino]

I'm tempted to ask "but does it run Windows 95?"

I am trying to think which OS variants I was actually operating when main memory was around 1GB.

I believe Windows 95 and its ilk actually topped out at 512MB, so Windows NT 3.51 or 4.0, perhaps 2000 seem likely, I held on to AMD K2/KIII very long before I went with various AMD64 until the Q6600 thrashed them. But since AMD64 meant bridging the 4GB barrier of 32-bit, that must have been later.

Anyhow, at this point you'd want a RAM-less mode supported by the chip, if only for kicks, which allows you to actually run a fully functional 64-Bit OS only from cache...

Considering LGR couldn't get MS-DOS working properly on a Ryzen 1700, I'd say no. He got FreeDOS to work, but I don't know if Windows 95 can be installed on top of that.

The only problem with running in cache only is the 1.3GB of LLC is spread around the chiplets, so you'd actually have a NUMA system if you could even treat cache like addressable memory.

 

[bit_user]

Anyhow, at this point you'd want a RAM-less mode supported by the chip, if only for kicks, which allows you to actually run a fully functional 64-Bit OS only from cache...

Fun idea, but I think the L3 on each chiplet is only populated by the cores on that chiplet. So, to run in a DRAM-less mode (which would encounter all kinds of practical obstacles, let's be clear), you'd be limited to just 128 MB.

 

[bit_user]

Considering LGR couldn't get MS-DOS working properly on a Ryzen 1700, I'd say no. He got FreeDOS to work, but I don't know if Windows 95 can be installed on top of that.

Unlike Windows 3.1, I don't think Win 95 booted into DOS, first.

 

[snemarch]

Unlike Windows 3.1, I don't think Win 95 booted into DOS, first.

It KindaSorta™️ does – and if you boot to straight DOS mode, you can even run "win" to start from there. WinME was somewhat... different.

I used to run a manually stripped-down 95sr2 (I think I got it down to like 15 megs?) as basically a supercharged dos extender – didn't use a whole lot of Windows apps at the time, but it let me do preemptive multitasking of DOS applications, and the disk caching was a lot faster and more stable than smartdrv.

 

[sferguson]

I'm tempted to ask "but does it run Windows 95?"

I am trying to think which OS variants I was actually operating when main memory was around 1GB.

I believe Windows 95 and its ilk actually topped out at 512MB, so Windows NT 3.51 or 4.0, perhaps 2000 seem likely, I held on to AMD K2/KIII very long before I went with various AMD64 until the Q6600 thrashed them. But since AMD64 meant bridging the 4GB barrier of 32-bit, that must have been later.

Anyhow, at this point you'd want a RAM-less mode supported by the chip, if only for kicks, which allows you to actually run a fully functional 64-Bit OS only from cache...

When was himem.sys (it’s been a while, I might be remembering the wrong name) developed? I remember that file being present in some DOS systems that I used, but that might have been around the time of 98se… that took max RAM to 768MB, if I am remembering correctly.

 

[bit_user]

When was himem.sys (it’s been a while, I might be remembering the wrong name) developed? I remember that file being present in some DOS systems that I used,

According to this, it came with Windows 2.1 and MS DOS 5.0:

HIMEM.SYS - Wikipedia

en.wikipedia.org

IIRC, what it did was to let you access the 64 kB segment at the top of the address range. That's something even a 286 could do (hence, the logic of including it with Windows 2.1).

EMM386 was another popular "hack", during the late DOS era.

 

[snemarch]

IIRC, what it did was to let you access the 64 kB segment at the top of the address range. That's something even a 286 could do (hence, the logic of including it with Windows 2.1).

Not just that, it also implemented the XMS spec which gave access to the above-1-megabyte memory. EMM386 did the same, but using the EMS specification (which required using a bank area for copying to/from extended memory, whereas XMS iirc allowed physical access if you went to protected mode). Also, EMM386 set up VM86 mode, which meant some DOS extenders weren't able to load (but it had a way to do it, because Windows needed to be able switch to protected mode even if EMM386 was loaded). Also, throwing in VCPI as a keyword if anybody feels like going on a nostalgia trip.

The details are a bit hazy, it's been a couple of decades since I messed with DOS related technologies 😅

 

[bit_user]

Also, throwing in VCPI as a keyword if anybody feels like going on a nostalgia trip.

DPMI (DOS Protected Mode Interface) was the one which stuck in my head. I thought that's what EMM386 implemented, but I could easily be wrong about that.

Back in the day, all I really wanted was flat, 32-bit addressing. I had a 386 with 8 MB of RAM, but did all my programming on 16-bit DOS. When I eventually upgraded to Win NT 4.0, it felt so freeing to be able to malloc multiple arrays > 64 kB.

 

[snemarch]

DPMI (DOS Protected Mode Interface) was the one which stuck in my head. I thought that's what EMM386 implemented, but I could easily be wrong about that.

Nope, no DPMI – but it implemented VCPI, which was necessary for DOS extenders (and Windows... which is arguably one of the more complex DOS extenders 😉 ) to be able to switch to Ring 0.

Oh, and a clarification for my previous post: XMS had functions for copying memory blocks around, which is what you would do if you used XMS memory in a real mode application. But you could lock a memory block and get a 32bit linear address. I belive most DOS extenders relied on XMS for their memory allocation.

Watcom, djgpp, wdosx, Japheth's HX... Elegant weapons for a more civilised age.

 

[abufrejoval]

When was himem.sys (it’s been a while, I might be remembering the wrong name) developed? I remember that file being present in some DOS systems that I used, but that might have been around the time of 98se… that took max RAM to 768MB, if I am remembering correctly.

I don't remember the date either, and there was a large mix of technologies around, which tried to give DOS a bit more breathing space than the original 640k.

Early ones centered around technology like Intel's Above board, a memory expansion board that would map 64k in to the "device space" above 640k and then offer page selection registers to map various parts of the total of 1.5MB of RAM it had into that window. Don't remember the granularity or if you could have several smaller banks active e.g. for copying data between EMM segments, mostly because it was abstracted behind an API.

Actually the board allowed a split: some of the whopping 1.5MB could be used as extended memory (mapped above 1024k on 80286 CPUs), some for EMM.

Since I was running both Microport Unix in protected mode and DOS I permanently had to split my card into two pools, if I didn't want to mess with the DIP switches that set the barrier between boots... what a drag!

Himem I believe came much later and used the fact that actually most 80386 systems of the time allocated the first physical GB of RAM to that address space, essentially overlapping the device space. Sometimes it was used to copy (slow 8-Bit) BIOS code into "shadow RAM", sometimes the ISA device address space simply got priority e.g. for EGA/VGA graphics cards resulting in that RAM being unusable, but any segment that wasn't used for BIOS or peripherals could be used by DOS and that's what himem.sys made available. It might have also included the 64k-16 bytes of RAM one could address on a 80286 or higher using FFFF as a segment address and then offsets up to FFFF, if the address line 20 wasn't disabled by the keyboard controller (which it usually was for compatibility).

Those were desperate times, every byte counted ;-)

My Intel Aboave board probably had the price of an economy car (you guys just wouldn't believe what we paid for these Personal Computers!), but it came with two goodies: a "free" 80287 math co-processor and a free copy of Microsoft Windows 1.0.

Of course I was a GEM (from Digital Research) developer back than so I scoffed at Windows, but I certainly appreciated the FPU and the fact that I could even use it for my 80386 systems, which got rid of these silly RAM limitations and let me run a proper System V Release 3 Unix with virtual memory and demand paging (and OS/2)!