(expensive, but) mnt pocket-reform (arm 7" mini-laptop)

[DiTBho]

Now those like me who want to support non-x86 machines need to deal with PCI boards.
(I am not considering PCI express, I am only considering PCI, from v1.0 to v2.2)

.... what's the problem you may wonder, PCI should be "architecture independent by design" 

well ... that's exactly the problem: in theory yes, in practice no!

As soon as you want to plug in a RAID board into the PCI slot of an { HPPA, PowerPC, POWER, MIPS, ARM, SH4, SPARC } computer, you find that

• the board has a ROM
• the board ROM contains x86 code(1)
• the x86 code is required to configure and initialize the board controller (which is usually an industrial CPU={PPC4xx, i960 } with RAM, ROM, and dedicated hardware, plus a dual port ram to communicate to the PCI)
• the x86 code is written as "PC-BIOS extension", so it's all in "x86 real mode"

my Mallanox cards, my Adaptec cards, my Avid cards, my Matrox cards... I have many cards that work like this and if you want to use them with GNU/Linux in a non-x86 computer you have to reverse engineer the damn x86 code in that damned ROM to get what value goes into which register on the chip and in what order, plus other bus-mastering details.


Last time I emailed Alan Cox to get some good advice from him, he wrote me that it's such bad hacking that no one wants to do it, which is why many controllers are simply left in a semi-functional state and never work on RISC workstations.


edit:
(1) if you're really lucky, you might find OF-compatible alternative ROMs, thus containing OF scripts instead of x86 code. Usually { VGA-card, RAID-1 } card for { PowerMac, SparcStation }

[DiTBho]

plus, PCI should be "architecture independent by design", but in practice, you also have to deal with architecture-specific aperture to PCI_IO_port and PCI_MEM_port.

So it's software + hardware series of incompatibilities that happen because the vendors don't meet the PCI/PCIe spec since their profit is already OK if they just do the minimum to make their cards strictly x86 compatible.

Usually, a lot of PCI and even PCIe boards are designed with x86 in mind and won't work with other architectures, for example, because they impose 64-bit access only and refuse to slip into two transactions as they should.

Or, worse still because they force specific-memory addresses in their DMA engine, and these addresses are not programmable and only work with PC memory layout.

Is this why you can't properly see a modern PCIe GPU working with { RPI CM4, PowerMac-G5, ... }

It's because x86 rules everything and people just don't care about anything else.

[james_s]

This is some kind of bizarre ideological crusade, there is no valid technical reason to have such a strong view on computer architecture. No ordinary person cares how a computer works under the hood and even most technical people only care in so far as they need to know in order to successfully develop software. All that really matters is Cost, performance, reliability, and compatibility with the software you want to run and support of any peripherals you want to use, these latter two points being the most important. There's a reason x86 absolutely dominates every area of computing except for mobile where low power consumption is paramount and closed ecosystems eliminate the need to worry about compatibility. Computers are nothing but tools, they exist to run software and all the technical elegance in the world is useless if it doesn't run the software that somebody needs to use. ARM, SPARC, PowerPC, x86, etc, as long as the software you need is compiled to work on it, you'd never know what was inside the box if nobody told you.

[james_s]

This is exactly the reason why I said computer science in 2023 is utterly depressing: because we know x86 is a very narrow-minded architecture brought with itself, but who cares? Just let's go on buying it because it's so crazy cheap.

Exactly, let's go on buying it because it's crazy cheap, and it works. You still haven't articulated WHY this is bad, unless perhaps you just pine for the early days of personal computers when there were numerous different competing architectures, nothing was standardized and some actually had tangible advantages and disadvantages. Now it doesn't matter, things have converged and matured, Linux is Linux is Linux and runs on practically every architecture on the planet. Maybe you want to throw away extra money but I think that being as cheap as possible is a great thing, provided that it works properly. I don't think computer science is depressing at all, on the contrary it's as exciting and more accessible than it has ever been. When I was growing up a computer cost a fortune and most people were not fortunate enough to own one. Now you can get a computer for $10 that outperforms a $40k Sun workstation of the 90s. I can assure you that 30-50 years in the future computers will be even more cheap, ubiquitous and mundane than they are today, and even fewer people will care how they work.

[DiTBho]

This is some kind of bizarre ideological crusade, there is no valid technical reason to have such a strong view on computer architecture. No ordinary person cares how a computer works under the hood and even most technical people only care in so far as they need to know in order to successfully develop software.

usually, those who talk to me obsessively about software compatibility, today that there are good open source apps, are the ones who have GB of cracked software on their hard drives

+= legal reasons

All that really matters is Cost, performance, reliability, and compatibility with the software you want to run and support of any peripherals you want to use, these latter two points being the most important. There's a reason x86 absolutely dominates every area of computing except for mobile where low power consumption is paramount and closed ecosystems eliminate the need to worry about compatibility.

Sure, so let's still design CPUs that ensure CP/M compatibility, it will take us to Mars 

Does it sound stupid? ridiculous? Well, Professor Andrew Tanenbaum pointed out more than 20 years ago, that's precisely what Intel has been doing for decades since the compatibility you're talking about is with 8085.

8085 << 8086

if people like you were in the minority and started wanting to understand something about computers, it would be clear that IBM POWER10 has already proven to be superior in terms of design, scalability (even vs XEON-x86), and power consumption, as well as the ARM Apple M1 and M2 have already proven to be much more efficient than x86.

do you want to be pragmatic to get the masses to get rid of x86?

give them

• A solid OpenSource OS: { GNU/Linux, FreeBSD, GNU/Haiku, ... } are good candidates here
• lot of peripherals, { GPU, RAID, Gigacards, ...}, so here it is why I am "re-purposing" x86-boards on non-x86 machines
• Solid OpenSource and OpenHardware support, so the same source can be recompiled on different platforms with less trouble
• Outstanding battery management on mobile devices
• Outstanding multicore facilities management and on both hw and sw sides

What's one of the things that matters to you the most when you're around on a battery-powered mobile device?
Bingo, when on x86 laptops you have less than 8 hours, with the same battery you can operate for 20 hours on an Apple M1 laptop.

What's one of the things that matters to you the most when you need massively parallel computing?
Bingo, strong and reliable memory models to run your stuff on as many cores as possible, and when an intel XEON has already demonstrated to be a bandwagon full of limitations, POWER9 and ARM64-Ampera can run up to 128 cores with a quarter of the problems you have with XEON

So, I hope people like you disappear with the end of x86, and there's a lot of hope even with RISC-V for the new generation who grew up on bread and raspberryPI instead of that x86 crap I grew up on.

[SiliconWizard]

You sound angry.

[DiTBho]

You sound angry.

Even on YouTube, there is a dude fighting with GPUs and other "made with PC in mind" peripherals since he would like to use them with his RPI-CM4, and ... they just don't work.

Nobody - not even engineers at AMD (at least, those who are allowed to speak) - knows why 

but if you look at comments, there is always someone - "hey, ok? why are you doing so? that GPU perfectly works in my PeeeeCeeee, and my PeeeeeCeeeee costs a quarter of effort and money of your setup" -

[DiTBho]

Talking about GPUs ... I have to understand how much "open" is this one 

some have nothing but binary blobs, and you end up using them as not-accelerated framebuffer.

[james_s]

Sure, so let's still design CPUs that ensure CP/M compatibility, it will take us to Mars 

Does it sound stupid? ridiculous? Well, Professor Andrew Tanenbaum pointed out more than 20 years ago, that's precisely what Intel has been doing for decades since the compatibility you're talking about is with 8085.

If there was a massive library of currently relevant CP/M software in use then no, it doesn't sound stupid at all to design CPUs that offer CP/M compatibility, it sounds like common sense. As it turns out though, that isn't the landscape we have, there is not currently relevant CP/M software, there IS however a massive library of relevant x86 software, so it absolutely makes sense to design x86 compatible processors and *shock* that is precisely what the market is doing. CP/M is far more advanced than the computer technology that took us to the moon so I have no doubt that it would be perfectly capable of getting us to Mars, as would any of the other far more modern architectures. You might be surprised at the sort of primitive CPUs that still find use in satellites and spacecraft as radiation hardened parts. Nobody cares what the CPU architecture is provided it does the job and runs the software they want to run.

Forget consumers for a moment because most of them already ARE using ARM CPUs in their smartphones and tablets, and look at professionals. Solidworks which my friend's business uses requires Windows on x86. Photoshop now supports M1 but until Apple switched it required x86. Altium Designer, requires Windows on x86, If you want to develop for FPGAs you have Vivado, ISE, Quartus, and whatever the Lattice toolset is called, requires x86. These are just a few examples but they are defacto industry standards that are in use all over, and if you want to sell workstations they have to support this stuff. Over 90% of personal computers in the entire world run Windows on x86 processors, I see absolutely no reason to move away from x86 for most of these applications, it's the most well supported by far, and it works, and it's cheap. You still haven't explained what's wrong with x86 other than "it's been around a long time", yeah well so has the wheel and the lever, hammers, circular saws and screwdrivers. I'm not ideological about my tools, I use what works and I don't care what is going on inside the box. Why should I?

[james_s]

Even on YouTube, there is a dude fighting with GPUs and other "made with PC in mind" peripherals since he would like to use them with his RPI-CM4, and ... they just don't work.

Nobody - not even engineers at AMD (at least, those who are allowed to speak) - knows why 

but if you look at comments, there is always someone - "hey, ok? why are you doing so? that GPU perfectly works in my PeeeeCeeee, and my PeeeeeCeeeee costs a quarter of effort and money of your setup" -

I agree completely. The devices are designed, marketed and tested for systems that make up 90% of the market, ie x86 Windows PCs. Why don't they work on other systems? Because nobody bothered to make sure they would do so, nobody has tested them on that hardware, it's not a supported configuration. So yes, "why are you doing so" is the question I'd ask too. Why would you make life difficult by trying to use an untested and unsupported configuration that costs more and doesn't work when you can easily buy a system that it is fully supported and will just work out of the box? And when your unsupported hardware doesn't work, why would you complain about it? It's not a supported configuration.

[SiliconWizard]

You sound angry.

Even on YouTube, there is a dude fighting with GPUs and other "made with PC in mind" peripherals since he would like to use them with his RPI-CM4, and ... they just don't work.

Nobody - not even engineers at AMD (at least, those who are allowed to speak) - knows why 

but if you look at comments, there is always someone - "hey, ok? why are you doing so? that GPU perfectly works in my PeeeeCeeee, and my PeeeeeCeeeee costs a quarter of effort and money of your setup" -

I understand your concern, but it's hard to blame companies for making stuff that actually sells and makes money. And sure they almost all make shortcuts regarding full compliance with standards, just barely making it for the markets they target. That most of the designers of said hardware don't even know why it doesn't work outside of what's been targeted is no surprise either, you can't battle on all fronts. I find that frustrating too, but I don't really know how that could be otherwise.

[james_s]

I understand your concern, but it's hard to blame companies for making stuff that actually sells and makes money. And sure they almost all make shortcuts regarding full compliance with standards, just barely making it for the markets they target. That most of the designers of said hardware don't even know why it doesn't work outside of what's been targeted is no surprise either, you can't battle on all fronts. I find that frustrating too, but I don't really know how that could be otherwise.

Exactly, they don't know why it works because they haven't investigated. They haven't investigated because they aren't being paid to troubleshoot why an unsupported configuration doesn't work. Most of us involved in developing products don't do it for fun, we do it for a paycheck, and if my boss doesn't want me spending company time testing on a platform we don't claim to support then I'm not going to do it. Maybe it works, maybe it doesn't, but if it's not something we claim to support then I don't care, it's hard enough just making sure something works properly with the supported configurations. Want some other platform supported? Make a business case for doing so.

[DiTBho]

(Why Intel x86 will DIE sooner than you think!)

 

[james_s]

(Why Intel x86 will DIE sooner than you think!)

 

LOL it's a year later and x86 is still by far the most popular desktop platform. Your hatred for it and the fact that you wish it would die doesn't mean it will. Have you noticed that nobody else here shares your strange hatred of the architecture? Most people simply don't care.

https://www.counterpointresearch.com/arm-based-pcs-to-nearly-double-market-share-by-2027/

ARM is predicted to double market share by 2027, reaching 25%. x86 still well over 60% still at that point, it's not going anywhere.

[DiTBho]

"in the future, it will be different, everyone will be running free GNU on their RISC computer [...]" (Tanenbaum)


mnt pocket-reform pre-ordered, review coming soon.
PM me if I forget to update this thread.

[brucehoult]

Nobody cares what the CPU architecture is provided it does the job and runs the software they want to run.

I totally agree. And yet you insist that architecture should be x86.

Forget consumers for a moment because most of them already ARE using ARM CPUs in their smartphones and tablets, and look at professionals. Solidworks which my friend's business uses requires Windows on x86. Photoshop now supports M1 but until Apple switched it required x86. Altium Designer, requires Windows on x86, If you want to develop for FPGAs you have Vivado, ISE, Quartus, and whatever the Lattice toolset is called, requires x86. These are just a few examples but they are defacto industry standards that are in use all over, and if you want to sell workstations they have to support this stuff.

That's weird. Just a few hours ago I was reading messages where you took the exact opposite point of view, that the number of professionals using such tools (or in that case IIRC it was about assembly language and debuggers) is so small that they are irrelevant and they can use whatever they want but it doesn't affect the real computer market.

I don't think you are arguing honestly, but just a troll.

Also, point of order, your honour:

"Photoshop now supports M1 but until Apple switched it required x86."

Photoshop has been around for 36 years and I was using it myself in the 1980s.  It was running on x86 Macs for only 15 of those years.

In fact less, as CS3 with Intel Mac compatibility was released only in April 2007, 15 months after the first mass-production Intel Macs, and almost two years after the Apple Developer Transition Kit (with a Pentium 4) was made available to all registered developers in June 2005 (Adobe probably could get them quite a bit earlier).

Prior to x86, Photoshop of course for the first seven years ran only on the M68k, and then for a dozen years on PowerPC. It was ported to PowerPC (Mac) and x86 (Windows) at around the same time in 1993-1994.

Adobe got Photoshop for Arm Macs out in March 2021, only four months after the first machines went on sale -- a much better effort from them.

[SiliconWizard]

I would expect much more porting efforts due to changes in the OS API rather than changes of the underlying CPU ISA, unless the software is written in assembly or using a non-standard language.
Now the transition from 68k to PowerPC was probably more difficult, as it was not uncommon back in the days to resort to various tricks and assembly to get acceptable performance.

These days, unless you're writing an OS, the ISA doesn't matter much as far as porting software goes.

[brucehoult]

These days, unless you're writing an OS, the ISA doesn't matter much as far as porting software goes.

For generic software written in standard C/C++ or similar, I agree.

It's a bit different for media processing software where you want to take as much advantage as possible of whatever SIMD instructions the ISA has -- which is not at all standardised. Even on x86, SSE, AVX, AVX512 are rather different from each other -- not just a register size difference.

Or is it all farmed off to the GPU using OpenCL/CUDA these days? I dunno.

I do know that the FFmpeg list has had a thread the last week or two with support for RISC-V V extension 1.0 being upstreamed.

I expect machines with SVE or RVV and either long registers or else lots of small CPU cores, each with a vector unit, will take a lot of GPGPU work off GPUs in the coming years. They are just so much more tightly integrated with normal scalar code. Both SVE and RVV have the features needed to efficiently run SIMT code using one vector lane per "thread"/"CUDA core" and one CPU core per "warp"/"wavefront". 512-2048 bit vector registers match typical GPU warp sizes. Per-lane predication allows you to implement divergent/convergent control flow.

[DiTBho]

These days, unless you're writing an OS, the ISA doesn't matter much as far as porting software goes.

don't forget "my-c". Currently, it only targets MIPS5++

So, for me, the ISA matters a lot for
- cryptographic extension
- writing an HL language(1)(2)
- ICE support


(1) things like this are insane, anyway insanely interesting, just don't do it (again)!

(2) take advantage of sane and well-made memory barriers, at most supported by specific ISA points, at the limit I'm fine with the fact that in the ISA a special class of load/store is foreseen, rather than letting some botched implementation solutions - then called "weak memory barrier" - put a patch on it

[DiTBho]

Then, talking about bizarre, what's the point of putting Minix inside an intel On-chip Management Engine?

Intel CPU On-chip Management Engine Runs on MINIX
by btarunr Nov 6th, 2017

With the transition to multi-core processors, and multi-core processors with integrated core-logic (chipset), the need arose for a low-level SoC embedded into the processor with just enough compute power to make sure all the components you pay for start-up and function as advertised. Enter the Intel ME (management engine). This is a full-fledged computer within your Intel processor, which isn't exposed to you. It runs on its very own tiny x86 CPU core that isn't exposed, and its software is driven on an infinitesimally small ROM and RAM. Since you can't have software without some sort of operating-system, Intel chose MINIX for the job.

MINIX is a Unix-like OS with an extremely small memory footprint. The OS was designed by Andrew Tanenbaum, originally as an educational tool to demonstrate that machines can still be built with extremely tiny code. If you're familiar with the "ring-level" system of hardware-access privilege by software, ring 0 would designate the "highest" level of access. A software with ring 0 access can erase your disk, flash your system BIOS, and even make your CPU run at any C-state. The OS kernel needs these privileges, and hence is a ring 0 software. Most user software, like the web-browser you're reading this on, runs at ring 3 (with the browser's own sandbox, the user-level, and API level forming inner levels). Intel ME runs at ring -3 (negative 3), and your OS has no power over it. Most system BIOS updates for Intel motherboards include a ROM update for ME. ME governs the functioning of the rest of the processor, its start-up, and booting. It also governs silicon-level security and management features that can't be compromised by malware.

An Open Letter to Intel, Dr. Tanenbaum.



Allwinner does something similar and with a rather buggy OR-core to manage their ARM SoC(1).
But at least it's documented, you know it's there, and you can entirely disable it!


(1) e.g. I patched u-boot to disable the OR-core in my NeoPI platform

[SiliconWizard]

These days, unless you're writing an OS, the ISA doesn't matter much as far as porting software goes.

don't forget "my-c". Currently, it only targets MIPS5++

Yes of course, if you're maintaining your own language and developing very low-level stuff, then surely it matters.

Anyway, x86 will die, eventually.
As I said in another thread, what has made Intel will eventually kill it. That's the rule.
Not saying it's gonna happen tomorrow, but it will happen.
And the market will do all it can to prevent Intel from transitioning to something else. Again, that's the rule.
So, curious to see how it will all unfold.

[james_s]

I totally agree. And yet you insist that architecture should be x86.

I don't actually. I have a handful of ARM based platforms I actively use and they work just fine because they support the software I want to run on them, my employer issued laptop is M1 based and again it works fine for me because it runs all the software I need to do my job. Nowhere have I insisted that everything should be x86, I have only pointed out why x86 is and will likely remain dominant in many markets for a long time and I defend it against ridiculous claims of it being worthless garbage because obviously it works just fine. I personally have a need for at least SOME x86 machines because I want compatibility with the software, however if somebody builds a machine with some totally different CPU architecture that can seamlessly run x86 software via a compatibility layer I'm totally fine with that too, because ultimately it's the software compatibility I care about, along with low cost and reasonable performance. How it works under the hood makes no difference to me, if you can make a 6502, Z80 , Sparc, ARM, whatever run my software acceptably well then great.

[james_s]

That's weird. Just a few hours ago I was reading messages where you took the exact opposite point of view, that the number of professionals using such tools (or in that case IIRC it was about assembly language and debuggers) is so small that they are irrelevant and they can use whatever they want but it doesn't affect the real computer market.

I don't think you are arguing honestly, but just a troll.

Also, point of order, your honour:

"Photoshop now supports M1 but until Apple switched it required x86."

Photoshop has been around for 36 years and I was using it myself in the 1980s.  It was running on x86 Macs for only 15 of those years.

In fact less, as CS3 with Intel Mac compatibility was released only in April 2007, 15 months after the first mass-production Intel Macs, and almost two years after the Apple Developer Transition Kit (with a Pentium 4) was made available to all registered developers in June 2005 (Adobe probably could get them quite a bit earlier).

Prior to x86, Photoshop of course for the first seven years ran only on the M68k, and then for a dozen years on PowerPC. It was ported to PowerPC (Mac) and x86 (Windows) at around the same time in 1993-1994.

Adobe got Photoshop for Arm Macs out in March 2021, only four months after the first machines went on sale -- a much better effort from them.

No I'm not just trolling.

I forgot about Photoshop on 68k, ironically I have a whole stack of 68k Macs and have used Photoshop on them, however they are ancient, and I suppose I could have said versions of Photoshop made in the last ~20 years which is what absolutely everyone using Photoshop professionally is going to be using, required x86, and even now it will not run on any random platform, it requires either Windows x86, or Mac x86 or M1, there are no other choices that I'm aware of. M68k is pretty much irrelevant since no remotely current supported version works on that.

I also don't see what is opposite about my other statement. The number of people writing BIOS, debuggers or other very low level stuff is extremely small and is irrelevant compared to the number of people using software in professional environments. I've worked in the software industry for close to 25 years now and the VAST majority of productivity software I have ever touched in a professional capacity required either Windows or Mac.