Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

JMacHack

Suspended
Mar 16, 2017
1,965
2,424
They’re really simple if you’re a CPU designer :)
I got two brain cells left and they’re both fighting for third. ? I’ll stick with my voodoo explanation.


Nvidia, which is looking to buy ARM, was built on gaming revenue and it's still a huge part of its business. If the mainstream corporate world remains closed to Apple, I think Apple also passing on AAA gaming is leaving another big slice of the market to Windows.

Frankly if Apple made a fantastic gaming machine hardly any “AAA Gamers” would buy it. The group is actively hostile to Apple. It would be a huge waste of time and money.
 

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
Haha that's great :p How'd you detect when it was overwritten? Did you just regularly check that the value of something matched expectation? Did you have clock interrupts so you could regularly check? Or did you just wait on sys calls?
And you were correct about 0x0 being div/0. 0x02 is the non-maskable interrupt :)
I had a timer api that consolidated timer interrupts and pushed them to a priority queue that ran after the interrupt returned via the scheduler. So it was a relatively low priority timer task on the timer priority queue. The timer tasks would run with interrupts enabled but before the scheduler would swap back to the highest priority background task. The timer tasks had to be reentrant which was a pain but the scheduler was non-preemptive so if the timer tasks took too long or any background task took too long, a watchdog timer would throw an error and stop the offending process or halt the system if it was system software.

The system had a bunch of S100 boards that each had custom firmware for the hard real-time tasks.
 
Last edited:

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
We used BADF00D for RAM returned by MALLOC to try to catch uninitialized memory segments.
Yeah, I think that is where I stole it from. 0xBADF00D had been used for years.

Edit: My use of 0xDEADBEEF was around 1986-1987.
 

jinnyman

macrumors 6502a
Sep 2, 2011
762
671
Lincolnshire, IL
In mobile sector, I'm not worried. But for prosumers and professional, I suspect we will eventually see diminishing foot print as times goes on. I don't see Apple putting down resources in workstation grade or highend desktop grade Apple silicon just to meet relatively small demand.

By the same logic, I'm not sure if Apple is willing to develop a competitive external GPU that can compete RTX 3080 ~ 3090.
 

bradl

macrumors 603
Jun 16, 2008
5,952
17,447
In mobile sector, I'm not worried. But for prosumers and professional, I suspect we will eventually see diminishing foot print as times goes on. I don't see Apple putting down resources in workstation grade or highend desktop grade Apple silicon just to meet relatively small demand.

By the same logic, I'm not sure if Apple is willing to develop a competitive external GPU that can compete RTX 3080 ~ 3090.

I'm not too sure on that. There are even projects used by a lot of companies that are putting together clusters of Mac minis for distributed computing, especially with Kubernetes, because the CPUs have the processing speed and the lower power footprint. And those are from the same workstation and desktop grade Silicon that are coming out now.

BL.
 

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
In mobile sector, I'm not worried. But for prosumers and professional, I suspect we will eventually see diminishing foot print as times goes on. I don't see Apple putting down resources in workstation grade or highend desktop grade Apple silicon just to meet relatively small demand.

By the same logic, I'm not sure if Apple is willing to develop a competitive external GPU that can compete RTX 3080 ~ 3090.
To reach NVIDIA GeForce RTX 3090 performance would take about 8 times the current 8 core M1 GPU. That would be 64 cores. That is doable without needing an external GPU. It just requires very high memory bandwidth which is probably going to have to be HBM2 with a wide memory bus. The rumor is that Apple is working on a 64 and 128 core GPU. No one knows if that is going to be on the motherboard of the ASi Mac Pro or on a separate card.
 

casperes1996

macrumors 604
Jan 26, 2014
7,599
5,770
Horsens, Denmark
I had a timer api that consolidated timer interrupts and pushed them to a priority queue that ran after the interrupt returned via the scheduler. So it was a relatively low priority timer task on the timer priority queue. The timer tasks would run with interrupts enabled but before the scheduler would swap back to the highest priority background task. The timer tasks had to be reentrant which was a pain but the scheduler was non-preemptive so if the timer tasks took too long or any background task took too long, a watchdog timer would throw an error and stop the offending process or halt the system if it was system software.

The system had a bunch of S100 boards that each had custom firmware for the hard real-time tasks.

That's awesome :) Love stories like this.
 

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
That's awesome :) Love stories like this.
I wanted to submit the OS for a master's thesis but the company wouldn't allow it. I wrote about 80% of the OS myself with a bit of help from a couple of other developers. The big help was the PC guy who understood the Microsoft .exe format and wrote the dynamic module loader. The executables had to come from tape though since we didn't have a floppy or hard drive card. But we could use the standard Microsoft linker software to build the executables.
 

JMacHack

Suspended
Mar 16, 2017
1,965
2,424
I think the standard explanation is that a pointer is like a mailing address, or something. I think when you start with the **foo stuff, that doesn’t help people.
I know enough to be dangerous but not enough to earn money with. About the most in depth stuff I’ve read is a couple books on the Wolfenstein 3D and DOOM engines by Fabien Sanglard. You may enjoy them in fact, I recall some documentation about the 386(?) having some weird extended addresses in which two pointers might “share” an address but not be “equal”.
 

casperes1996

macrumors 604
Jan 26, 2014
7,599
5,770
Horsens, Denmark
I know enough to be dangerous but not enough to earn money with. About the most in depth stuff I’ve read is a couple books on the Wolfenstein 3D and DOOM engines by Fabien Sanglard. You may enjoy them in fact, I recall some documentation about the 386(?) having some weird extended addresses in which two pointers might “share” an address but not be “equal”.

While I don't know that much about the world of the old chips, that sounds like something that could happen when the A20 gate wasn't active so you'd have wrap-around after 1M. It could also be something to do with the segmentation system that was prevalent before paging
 

casperes1996

macrumors 604
Jan 26, 2014
7,599
5,770
Horsens, Denmark
I wanted to submit the OS for a master's thesis but the company wouldn't allow it. I wrote about 80% of the OS myself with a bit of help from a couple of other developers. The big help was the PC guy who understood the Microsoft .exe format and wrote the dynamic module loader. The executables had to come from tape though since we didn't have a floppy or hard drive card. But we could use the standard Microsoft linker software to build the executables.

A shame you couldn't do it. - But what were you binary compatible with (a subset of) Microsoft .exe binaries then or what? Emulated the same system call behaviour too or did you just use the same format? I would've assumed potential legality concerns there.
I wrote my OS for a bachelor project (design almost entirely taken from JOS - an MIT designed OS so it was more implementing it than designing it from scratch) and we just used ELF as our executable format. Nice because the documentation for it is readily available and you can easily generate ELF binaries with gcc. So our kernel itself was an ELF binary, had a classic MBR style boot loader (getting under 512 bytes can be tricky :p ) and so the code to load in a program inside the kernel and to load the kernel itself from the boot loader was pretty similar since both were ELF. Though the boot loader didn't make as many checks - like it didn't check if the ELF binary represented an executable or a dynamic library, it just assumed it was the kernel. - But yeah, fun stuff, haha.
 

cmaier

Suspended
Jul 25, 2007
25,405
33,474
California
I know enough to be dangerous but not enough to earn money with. About the most in depth stuff I’ve read is a couple books on the Wolfenstein 3D and DOOM engines by Fabien Sanglard. You may enjoy them in fact, I recall some documentation about the 386(?) having some weird extended addresses in which two pointers might “share” an address but not be “equal”.
Yeah, that could happen in some circumstances. As an x86 CPU designer, I can tell you there are a lot of funky addressing modes. One way that could happen, I guess, is with pointer math. You can use []’s to offset a pointer and end up on the same address as another pointer, but the C run time doesn’t know that they are the same address and doesn’t care - they are different pointers.
 

BuddyTronic

macrumors 68000
Jul 11, 2008
1,881
1,484
The power is there, but AMD and even possibly Intel will catch up in time. I fear the future market fragmentation, with developers having to develop specifically for Apple Silicon ARM and just not having the time to do so.

Not to mention that games for Apple Silicon are just not a thing, and gaming is a huge part of the PC market, and realistically will probably never be a thing, since Apple and gaming just don't work together.

Even the new 10nm Intel CPUs will be much better than before, and AMD is already doing great in raw power.

The idea of Apple controlling both software and hardware is great, something they've been trying to do for decades, but the big question is how the support from the developers will be.

I look forward to the power, but I'm just not so sure about the future.

I am a complete noob and have no idea what I'm talking about in this area, but I'm just wondering what other people here
 

BuddyTronic

macrumors 68000
Jul 11, 2008
1,881
1,484
The power is there, but AMD and even possibly Intel will catch up in time. I fear the future market fragmentation, with developers having to develop specifically for Apple Silicon ARM and just not having the time to do so.

Not to mention that games for Apple Silicon are just not a thing, and gaming is a huge part of the PC market, and realistically will probably never be a thing, since Apple and gaming just don't work together.

Even the new 10nm Intel CPUs will be much better than before, and AMD is already doing great in raw power.

The idea of Apple controlling both software and hardware is great, something they've been trying to do for decades, but the big question is how the support from the developers will be.

I look forward to the power, but I'm just not so sure about the future.

I am a complete noob and have no idea what I'm talking about in this area, but I'm just wondering what other people here think.

When we talk about Intel or AMD “catching up” it’s kind of a funny thing because Intel’s best stuff is made by TSM and the same thing for AMD and the same thing for Nvidia.

if TSM took a 3 year holiday, Intel could catch up maybe.

It will take espionage to beat TSM. From Intel? Or China? Or Samsung?
 

throAU

macrumors G3
Feb 13, 2012
9,206
7,364
Perth, Western Australia
What's wrong with assembler?

Portability and maintainability mostly.

It has its place, but it isn't writing application code in the 21st century.



edit:
I say this as someone who wrote some little games back in the 1990s in a mix of Pascal and inline x86 assembler (mostly to program the VGA display hardware directly and speed up drawing routines for sprites, lines, screen double buffering, etc.).
 

jdb8167

macrumors 601
Nov 17, 2008
4,859
4,599
A shame you couldn't do it. - But what were you binary compatible with (a subset of) Microsoft .exe binaries then or what? Emulated the same system call behaviour too or did you just use the same format? I would've assumed potential legality concerns there.
I wrote my OS for a bachelor project (design almost entirely taken from JOS - an MIT designed OS so it was more implementing it than designing it from scratch) and we just used ELF as our executable format. Nice because the documentation for it is readily available and you can easily generate ELF binaries with gcc. So our kernel itself was an ELF binary, had a classic MBR style boot loader (getting under 512 bytes can be tricky :p ) and so the code to load in a program inside the kernel and to load the kernel itself from the boot loader was pretty similar since both were ELF. Though the boot loader didn't make as many checks - like it didn't check if the ELF binary represented an executable or a dynamic library, it just assumed it was the kernel. - But yeah, fun stuff, haha.
No ABI compatibility. We had a mechanism to do dynamic dispatch. Each external procedure was manually installed into the dispatch table with the offsets linked with each application. We only had a few 100s of KBs for the ROM code so it was pretty doable. The dispatch table had a bit less than 512 entries.
 
  • Like
Reactions: casperes1996

Leon1das

macrumors 6502
Dec 26, 2020
285
214
Apple is hardware company - I am not worried at all for the future of Apple Silicon.
If it pushes the others manufacturers on the same route of innovation - and they surpass Apple - Apple will just switch to their hardware, as they want the best inside their devices.

Biggest enemy for Apple is on the software side happening now - whole CSAM initiative is seriously shaking their privacy-first company approach.
 
  • Like
Reactions: bobcomer

senttoschool

macrumors 68030
Nov 2, 2017
2,626
5,482
To reach NVIDIA GeForce RTX 3090 performance would take about 8 times the current 8 core M1 GPU. That would be 64 cores. That is doable without needing an external GPU. It just requires very high memory bandwidth which is probably going to have to be HBM2 with a wide memory bus. The rumor is that Apple is working on a 64 and 128 core GPU. No one knows if that is going to be on the motherboard of the ASi Mac Pro or on a separate card.
How did you arrive at 8?

RTX 3090 has 35.6 FP32 tflops. M1 has 2.6 FP32 tflops. If you go by this alone, you'd need 13.68 M1 GPUs. That would need 109 M1 GPU cores.

But tflops are not longer reliable in terms of estimating performance: https://www.engadget.com/nvidia-rtx-3090-3080-3070-cuda-core-int32-fp32-210059544.html
 
  • Like
Reactions: jdb8167

Kung gu

Suspended
Oct 20, 2018
1,379
2,434
If it pushes the others manufacturers on the same route of innovation - and they surpass Apple - Apple will just switch to their hardware, as they want the best inside their devices.
or Apple will try to surpass those companies who surpassed them. Pretty sure Apple won't depend on others for their CPUs or GPUs anymore.
Biggest enemy for Apple is on the software side happening now - whole CSAM initiative is seriously shaking their privacy-first company approach.
The majority of people don't care really. This issue is not being talked in the mainstream media as the battery issue did.
 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,869
As a former x86-64 CPU designer (and, in fact, one of the first 15 such designers), I’ve often said intel and AMD should just drop legacy support. We designed AMD64 to be much easier to decode than legacy x86, and dropping support for 32 and 16 bit stuff would likely simplify the decoders a ton, allow much wider issue, etc. Still wouldn’t be as clean as a RISC architecture, of course.
Resurrecting this from earlier in the thread because there's one thing I've been curious about for a long time, and it's not often you get a chance to ask an insider: Did your team ever consider an approach to 64-bit encoding more like what Arm did in the v8 architecture spec?

If you're not familiar with it, putting an Arm v8 core in 64-bit mode means it cannot understand either of the 32-bit instruction encodings, and vice versa. Also important: 32/64-bit mode transitions are only possible as a side effect of exception level transitions (analagous to x86 ring levels).

Obviously there are some important limitations there (32-bit userspace code can't call 64-bit userspace libraries, and vice versa), but it permits designing a completely new encoding without any legacy baggage. And wow, does x86 have some baggage!

The PC industry as a whole seems to pathologically prefer messy layers of hacks rather than trying to start over, so I wouldn't be surprised to hear that you guys wanted to do something like that and got shot down by an outside partner. Or simply thought it over and decided to not even try to fight that battle.
 
  • Like
Reactions: satcomer
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.