The link seems to be getting the YCombinator hug-of-death. I can't read the article at all.
Since POWER9 only exists in the server / HEDT sphere, I doubt this will be a modern POWER9 chip. Maybe something like a NXP-chip, which would still be interesting. Something on the scale of a Chromebook maybe?
If binaries were compatible with the Talos II POWER9 HEDT / Server, then there is still a good use of this laptop. To serve as a portable development platform, much like Intel Atom can serve as a portable development platform for Intel Xeons.
Depends on a lot of details however. Honestly, its probably more important to rack-up a POWER9 Talos II and just SSH into it every once in a while... modern cloud-based services makes this sort of thing much easier.
----------
EDIT: Site finally worked for me. NXP T2080 chip, 4-core / 8-thread 28nm class chip. e6500 core, which is some form of PowerPC for sure... 128-bit vector units (Altivec). 32kB L1 d$ and 32kB L1 I$, 2MB L2$ for the whole chip.
This is older-tech for sure, definitely "Chromebook" level of tech, maybe a touch weaker even.
EDIT2: I think there's something to be said about an "open" design, where the schematics are available for the community to use and extend. The NXP T2080 has good GPIO pins and connectivity, so there's a chance that this laptop will be easier to interface with electronically than other devices. Guys over at hackaday probably would love something like this. https://gitlab.com/oshw-powerpc-notebook/powerpc-laptop-mobo...
If I followed the links correctly, it's a 1GHz-ish PPC derivative from a shop you for whom processors are a minor part of their product line. The motherboards linked to appear to all top out at 2GB of SoDIMM memory. So maybe "that's cool" but not "that's generally useful" and personally not "I'll spend money on that".
People are getting down-voted for asking what year it is, but I’m going to “what year is this?”
I’m not discounting the effort that goes into place here — at least I’m trying not to — but like, why would anyone look at PowerPC for portables in 2019 when the whole reason Apple shifted to Intel 14 years ago was thermals? Wouldn’t ARM be better?
I’m sure I’m missing something but I just don’t understand this on any level except for some obsession with “openness” at the expense of actually doing anything.
> when the whole reason Apple shifted to Intel 14 years ago was thermals? Wouldn’t ARM be better?
The move to Intel wasn't because the instruction set is, for some reason, superior (it isn't), it's because IBM couldn't keep up with Intel's fabrication technology. The G5 chip from 2002 was at 130nm, while the Intel design introduced in 2006 (when 4 year old G5 was the best IBM had to offer) was at 65nm.
The chip they aim for is built on a 28nm process (which has some impact on voltages used and minimum conversion of power into heat). That's definitely not top-class, but good enough: it's about a factor 3 to the state of the art (compared to factor 2 between G5 and Intel Core in 2006), but in absolute terms it's so much closer.
There are enough ARM laptops out there, this provides another venue for more vendor independence (ARM still exerts tight control over its ISA while PowerPC is a close cousin to Power9 which was opened recently). In short, for a project like this, the goal isn't the very best performance on the market, it's "the more the merrier".
Ok. but 28nm is nowhere close to where ARM is (7nm) and will be over the next few years (3nm). Smaller, faster, with multiple cores & on-board ML/Neural subsystems. The cost on the ARM side is always going to be lower due to the volume at which they are being dropped into phones. And if one wanted a faster x64 path, then why not AMD Rizen?
ARM isn't at 7nm, TSMC is. That's different from the PPC -> Intel transition at Apple 15 years ago: the tech is available to anybody who's willing to pay (while back then, Intel was 1-2 generations ahead of everybody else, and there was no indication that this would change).
The primary goal of a project like this is to prove the concept, and if 28nm NXP PPC chips are the sweet spot (enough performance for it to matter, unlike all those RISC-V micros; efficient enough to fit in a laptop without it working double-duty as a grill, unlike Power9 CPUs; cheap enough so that people are willing to risk it, unlike the otherwise fabulous TALOS workstation family) for that, that's not too bad.
In case this takes off, there can still be some entrepreneur who cooperates with IBM or NXP or whoever has an efficient Power implementation lying around and shrink it to the smallest process node they can afford, reusing this open hardware design, and send it off to TSMC. That option didn't really exist back in 2004.
"The more the merrier" isn't true for proprietary ISAs at all. Think of all the work going into supporting it, of the limitations coming with a very exotic computer. These are things humans have to spend lifetime on. I think it's a huge waste.
If this was about pushing RISC-V forward, I wouldn't say that, but only because I hope it takes over, not because I think having yet another ISA in the zoo is somehow good.
PowerPC has silly things like decimal-floats support and quad-precision support. I mean, they exist for emulating old COBOL code for the most part, but decimal-floats solve the age-old problem of how to represent financial data with floating-point, and with perfect accuracy at that.
There's certainly good and unique ideas in the PowerPC ISA.
Minor correction: Nvidia GPUs on POWER9 are connected using NVLink, which shares its physical layer with OpenCAPI, and like OpenCAPI is cache-coherent, etc, but uses a different data link and transport layer protocol.
(I'm one of the OpenCAPI Linux kernel driver maintainers)
RISC-V is pretty shoddy (M mode, a separate hypervisor mode instead of proper orthogonality, CSRs), but that's exactly what I'd expect from thesis-driven development (remember that RISC-V was an academic project for a long time).
Holding their feet to the fire so that they undo some of that damage seems to be a pretty good idea to me, and if it's PowerPC what it takes to do that, that's not the worst choice IMHO.
M mode isn't a hypervisor mode. It's more like x86 System Management Mode, or ARM's EL3. Hypervisor was originally going to be a separate H mode, but they made it orthongonal with S mode instead as a sort of bank switch.
And if CSRs are bad, then POWER's SPRs are bad; they're basically the same thing except POWER makes much less effort to be consistent or introspectable.
POWER is way more braindead in it's supervisor state. For instance they finally gave you a sane radix tree page table with POWER9, but now you can't address all the virtual address space you could before, which, yes, is its own problem for some systems.
As you say, it's similar to x86's SMM, and like all firmware stuff that survives beyond the kernel entry point, is something that I don't trust, and where experience tells me that it's a venue for vendors to mess things up.
One of the hardest issues with real time computing on x86 is... SMM. One of the easiest ways to bypass security on x86 is... SMM. The workaround for "securing" SMM is to sprinkle virtualization on it (STM: because more virtualization is always better), which only adds more complexity (and messes up real time computing even more).
And all that closed source because SoC/firmware vendors quickly and happily assume that such modes are owned by them, to the detriment of whoever wants to know what their machine is doing.
Not having such a mode helps keep vendors honest: if there's a need for a workaround, document it and kernel developers can implement it (and they will). None of that "install this firmware update that we don't tell you anything about in order to hopefully be slightly more secure than yesterday" crap.
> And they removed H mode.
Well, that's an improvement. Thanks for making me look it up again. One down, one to go.
> One of the hardest issues with real time computing on x86 is... SMM. One of the easiest ways to bypass security on x86 is... SMM. The workaround for "securing" SMM is to sprinkle virtualization on it (STM: because more virtualization is always better), which only adds more complexity (and messes up real time computing even more).
A question: To my knowledge, SMM runs in ring -2, while virtualization runs in ring -1 (i.e. is less privileged than SMM). So how can one "secure" SMM by using virtualization?
All rings below 0 are informal. Generally, SMM can control the environment of an hypervisor, so that's where that hierarchy comes from.
But: SMM is a relatively complete x86 computing environment. You can switch between real/protected/long mode, you can set up page tables. Apparently the only thing that is truly locked down is receiving further SMIs.
I was meaning to try to just run full Linux with processes within SMM, and I see no reason why that shouldn't work (except that it's probably a less well exercised CPU state, so I half expected to experience all kinds of oddities in that state). Never got to try that, though.
So SMM is more akin to AArch64's hierarchy (although I have no idea who came up with it first): there are privilege levels 0-3 (on x86: regular operation) and there are "secure" privilege levels 0-3 (on x86: SMM) - just without the security (see all the attacks successfully mounted against SMM).
(and yes, I'm also critical of the secure level stuff on ARM: Yet another place where I've seen crappy SoC vendor code routinely hidden. Although to their credit, ARM seems to have designed that mode with security from the start while SMM was more of a hackjob to support the first 386-based laptops which then grew way larger than it should have, like everything in 8086.)
> In case Mr 7 months' old account are wondering why you are downvoted, may I remind you this is HN, and not reddit.
Why would I care? These votes are worthless.
I keep noticing that people here are looking down on Reddit, as if HN was even comparable to Reddit. Lots of subreddits are high quality, lots of subreddits are junk. HN would be somewhere in the middle.
I'm guessing you're right. The Mac G5s are legendary, of course, for heat. I've worked with VMEBus G5 machines (PowerPC 970FX chips) and they were furnaces that needed force air cooling no matter how we played with frequency. I can't imagine putting one in a ThinkPad case.
I have to say, I'm really happy that this seems a sort of resurgence of a proper CPU architecture diversity. I'm getting bored of the x86/ARM dichotomy.
Having few instruction set architectures, or even one, enables quicker and more efficient software development by lowering barrier to entry (easier to learn and study just one ISA instead of many) and lowering the amount of maintenance and development work that has to be done on development infrastructure such as compilers.
This is assuming royalties don't have to be paid to an ISA creator, which is a separate issue.
A single ISA doesn't have to mean there is a single CPU vendor or CPU manufacturer.
In my opinion, having a single ISA breeds lazyness, and causes shortcuts to be made in programming. Like when the whole world got rid of all those esoteric 18-bit-word and worse architectures, and started writing loads of C for 32-bit i386. Then 64-bit came along and loads of software wouldn't compile properly without fixing things like assumptions of integer size, etc.
It's why I am very glad that while Linux is very popular, there is still a BSD keeping programmers from going too crazy on the Linux-only features.
We don't know what future architecture will exist. I would rather we have a multitude of architectures now, so that people write standards-conforming code rather than it-works-on-amd64/Linux code.
The 18- ad 36-bit architectures weren't esoteric at the time! Though may of them also had bad (outdated, and not-obviously bad at the time) ideas like one's complement arithmetic. Machines like the PDP-10 were a pleasure to program in assembly, but I haven't written a line of assembly code in over a decade.
But I agree the world is full of "slap it together and if it runs once, ship it" software -- that's what gave us Y2K. Time to re-read worse is better.
In retrospect, it's amazing how older games like Age of Empires work so well and (almost) bug free from the get go. In the software development environment for late 90s the amount of work to making sure that it works (without crashing!) is amazing.
With extreme logging now our team still throws a bunch of internal errors today, granted our team is much smaller but still, those older games are amazing.
> In my opinion, having a single ISA breeds lazyness, and causes shortcuts to be made in programming.
Aren't you aware that lazyness is one of the great virtues of a programmer?
> Then 64-bit came along and loads of software wouldn't compile properly without fixing things like assumptions of integer size, etc.
Yes, now you just write code with the assumption that a word is 4 or 8 bytes, you don't concern yourself with the case where the word is four triganic nibbles long.
I think it is appropriate to specify your statement with a significant detail; a ISA monoculture enables quicker and more efficient development of proprietary software. Free and open software deals efficiently and fast with different ISA's, as can be seen in the ports of Debian and the targets of GCC.
Free software is great, but it's not efficiently developed. That's why it's been so hard for people to get a satisfactory Linux on the desktop GUI and it's still a crapshoot to even get all of a laptop working .
I agree that there's a programmer cost to having a multiplicity of ISAs. However, ISAs still have some relation to the design of the microarchitecture, which for x86 processors is not open. The RISC-V ISA for instance was created mainly because it helped the effort to create open CPU hardware.
My usual take is that it gives us better efficiency in the short-term, at the expense of making it far more likely that we get stuck in a rut long-term.
I'll celebrate implementation diversity, but I'm not sure why I'd celebrate interface diversity. All it does is create pointless incompatibilities that users have to deal with.
I think it's great that many companies have their own implementation of open standards like Unicode, TCP/IP, and SMTP. Life was worse in every way when every company had their own special encodings for text files, and their own proprietary network protocols. I can type some text in Japanese and email it to a friend, in 2019, and it will just work. Excellent!
The continued survival of x86 and other proprietary instruction sets reeks to me of the days of the "Best Viewed with ${browser}" badges. It's purely a pain point for users, for what appears to be merely a battle of egos among the world's richest megacorporations.
Praising the growth of a third CPU opcode system sounds to me like wanting to bring back, say, the Scottish historical units of measurement, on the basis that we're "getting bored" with the SI/USCS duopoly. Bored is good! Bored means it works. I wish the USCS would die off, too, so I could be even more bored in that department.
SPARC has been open for a long time and there are numerous implementations. MIPS (and Longsoon) has been shipping forever. RISC-V is real. There's a project to create a re-implementation of SuperH.
It's not like x86 & ARM is the only thing in the world...it's just the only thing that matters economically right now.
Slimbook has made some excellent hardware in the past, with terrific software support. They're much closer to being the Macbooks of the Linux world than either Purism's or System76's offerings are.
Why is it "incredibly exciting"? Near as I can tell from the web site, it's a relatively very slow processor (~1GHz) with little memory (max 2Gb?). There are other "Open Platform" options with similar limitations (Longsoon).
It's exciting because having viable diversity in computer architectures is valuable.
Programming* for different architectures forces one to carefully consider their design choices, and provides an incredibly powerful incentive to write high quality portable code.
*This assumes that you can take the performance hit of not using platform-specific hardware / inline assembly.
As a related example, every few months I cycle between Windows, MacOS, Linux, and a handful of BSDs for my personal computing needs. Doing so has forced me to consider carefully what software I use, how I have my systems / environments set up, and which libraries are a good idea to use in development and which are not. I am a better linux developer for having an appreciation of freebsd's jails and macos's attention to design, a better openbsd user for having dealt with securing linux and windows boxes, etc.
It's not a matter of 'viable'. It's a fund raising exercise.
You don't need a PPC box to try out "Windows, MacOS, Linux, and a handful of BSDs".
If you need to play with slower, poorer supported hardware architectures, there are vast numbers of options, many of which don't require placing speculative bets on marginally performing hardware.
I don't, per se, disagree with anything you said, but nothing you said needs a seriously sub-par laptop to achieve.
>It's not a matter of 'viable'. It's a fund raising exercise.
As it stands there are very few usable PPC laptops, just like there are relatively few usable ARM laptops (although that is improving quite rapidly). The development of a modern PPC laptop would go pretty far towards making PPC a viable general purpose computing architecture, albeit one likely always reserved for enthusiasts.
>You don't need a PPC box to try out "Windows, MacOS, Linux, and a handful of BSDs".
I'm not saying that I need a PPC box to switch OS's, I'm saying that doing things on a different architecture is a good exercise and helps you learn things that can be improved your current one / shows you things that it does well that you should appreciate. It is a good exercise if you want to have a greater understanding and perspective on things you might ordinarily ignore.
The specs of their proposed laptop are indeed fairly weak, and last I checked PPC support was not particularly great in linux. There's also the issue of hardware bugs on a complex new system.
I completely understand people not being excited by this device, and even wondering why anybody would care. I care because it's different, and because I've seen significant value for myself in sometimes doing ordinary things differently.
The only problem is are PowerPC/Linux up to task? Correct if I'm wrong but from what I know the entire linux ecosystem is geared toward X86/64 and if you're on other architecture the selection of software that works shrinks substantially.
While we could just compile everything, there's still the problem of untested architecture integration, bugs that doesn't happen in X86 might happen in PowerPC/ARM and it's not a trivial issue to debug a compiler/bimodal action for instruction sets.
You would think this, but it's preeeetty amazing how much of the Linux world works on an ARM-based Raspberry Pi. It's mostly a matter of finding the source and doing a proper cross-compile, but it's kinda incredible how much work the community has put into making the little board usable. The later models and their substantial bump in available RAM have made desktop computing plausible: I can run Blender to produce a 3D model, switch to Utilimaker Cura to slice it, then run Pronsole and send the .gcode out to the printer, all on the same device! It's not particularly fast, but it's usable at least, and the driver support an OpenGL in particular have come a long, long way.
If a $35 (okay, $55 for the ones with 4 GB RAM) computer running an older down-clocked ARM can do this? I have little doubt that a POWER architecture could theoretically do it just as well, if not better since it should presumably be a much faster chip. I think it's mostly going to come down to support from both the vendor and the community, but I wouldn't write it off entirely.
> I have little doubt that a POWER architecture could theoretically do it just as well, if not better since it should presumably be a much faster chip. I think it's mostly going to come down to support from both the vendor and the community, but I wouldn't write it off entirely.
I actually think it'll come down to the validity of that first sentence I quoted. A Pi 4 definitely has relatively decent specs for a small server or low end laptop.
If this isn't a Power9 (aka the series that the G5 and the latest Power arch chips are a part of) then all this has going for it is the openness of it. Is it more open than a Pi 4? If they release a successor to the Compute Module 3+ with better specs and someone builds a laptop chassis around it, is there any reason I shouldn't just buy that?
Are you saying the end user should do the cross compile, or the package maintainer? I feel like for arm it's mostly been package maintainers who've been increasing the available software. For PowerPC, if the user needs to compile from source that is a big reason to avoid PPC IMO. A bit of a chicken and egg situation.
For the Pi in particular it's been a mix of both, I think. Its sheer popularity means that there's less pressure on the package maintainers to ship working builds; for example, you can technically "apt-get install cura" but it won't run, it crashes during initialization for unclear reasons. I'm running an AppImage of it put together by a community member. It's both exciting that this is even possible, and frustrating that it took so much research and tinkering.
I'm not sure why you're getting downvoted, because this is a really legit angle to argue. Philosophies aside, I think the out of box experience is critical to adoption of a device like this, and it's a big risk for Slimbook to take when switching to a much less popular architecture. For the Pi it was acceptable because it was sold as a development board for education, so "batteries not included" is a feature. For a device poised as a workstation, I'm not sure how well the frustrations of early adoption will go.
It's exciting that Slimbook is willing to take that risk, but it'll be up to the community to determine whether the devices (and their vendor support) are worth the cost of maintaining the packages in the long run.
EDIT: For clarity, the out of box experience on the Pi here refers to Raspian, which is a debian-based image put together by the vendor. There are lots of other distributions that can run on it, and some of them might have better luck with the edge cases I hit.
(disclosure: I'm a PowerPC kernel developer at IBM)
The PPC64LE Linux ecosystem is doing quite well, due in large part to the amount of effort that distributions (Red Hat, Ubuntu, Debian, SuSE) as well as IBM and its partners have been putting in to making sure Linux on Power is a competitive and fully supported server platform.
The focus has been on server software more than desktop software, the desktop ecosystem works well enough that most Raptor Talos II owners are happy but there are of course still a few gaps.
In the case of this notebook, they're using an older NXP QorIQ chip rather than a POWER8 or a POWER9, so things will be a little trickier for them, but at least when it comes to common open source software of the kind shipped in Linux distros, it's not at all insurmountable.
That's not accurate. For years I have run Linux (Debian and Gentoo mostly) on various architectures, including on an old PowerBook Pismo (G3) and an IBM Power 5, and I have rarely encountered architecture related limitations.
True, you will encounter issues (proprietary software, arch specific software (ex: chromium)), but these are not the norm. Wet fingering it, I would say at least 95% of packages worked without any issue, and this includes big things like Firefox, Libreoffice, OpenJDK, Apache...
I was a bit sad when Debian dropped support for ppc32.
> Correct if I'm wrong but from what I know the entire linux ecosystem is geared toward X86/64
That's not been my observation. I mean sure, AMD64 tends to be the primary platform for most desktop Linux users but Linux has been ported to so many different platforms and used in a lot more exotic hardware outside of the desktop domain.
Also this has reminded me one of the game servers myself and some friends on IRC used regularly was an old PowerPC desktop running Linux. Though that was a little while ago now.
I doubt that. At least not "an order of magnitude more". Bare in mind AMD64 is used heavily in servers where Linux also dominates. Even in cloud providers, most of their services will be Linux under the hood.
As someone who works for a server manufacturer I very much know how dominant both AMD64 and Linux are. But there's literally billions of Android phones out there.
The world population is "only" 7 billion so also doubt there's "literally billions" of Android phones out there once you discount iPhone users, non-smart phone users (eg many elderly), young kids, and people too poor to own a phone (homeless, people in developing countries, etc).
You might get more favourable figures if you also count old and unused Android handsets but then you'd have to do the same for Linux servers as well -- and Linux servers have been around a lot longer than Android phones have.
AWS alone had 1.3 million active servers in 2016 alone - most of which would have ran Linux. AWS has grown massively since then (averaging at around 40% year on year) so that figure has certainly raised significantly since then. Plus AWS might be the largest player in town but it's not the only one, so you'd have to include GCP, Azure, Oracle, OVH, Digital Ocean, etc. Not to mention all the literally thousands of other hosting providers out there. Then you have on-prem gear in schools, offices, shops, home labs, etc....and we've no way of estimating all the deprecated instances over the last 2 decades (longer to be frank, but lets round down for simplicities sake).
Where as Android is 11 years old and took a little while to gain momentum...?
Even if you only talk about tech in active use, people only need 1 phone (or maybe 2 if you have a separate work and personal phone). That one phone isn't automatically an Android and, as mentioned in my opening paragraph, a great many people don't even have phones to begin with. But lets just focus on those who do...each of those people will interact with more than one service. You'd interact with point of sale systems which would need a server backend. You'd interact either hundreds of online endpoints a day just browsing the web; and many of those endpoints would have a multitude of servers backing them. Not to mention online endpoints for games, mobile apps, etc. People's daily lives revolve around 1 or 2 phones but require so many more servers for all of that connectivity to work.
So I just don't see how Linux phones outnumber Linux servers by an order of magnitude. I think your estimations there are way off.
Also, being someone who "works for a server manufacturer" doesn't give your opinion here any more credibility. More than 90% of the people on here (myself included) could make similar arguments for authority. In fact I'd be more surprised if I was chatting someone who hadn't any professional experience in either servers nor mobile phones.
> ... also doubt there's "literally billions" of Android phones out there ...
> AWS alone had 1.3 million active servers in 2016 alone ...
According to a quick Google search:
In 2018, Samsung (alone) sold ~295 million phones [0].
In 4Q18, there were ~3 million servers sold (across all vendors) [1].
> Even if you only talk about tech in active use, people only need 1 phone ...
Here, between two of us, the girlfriend and myself, we've got at least seven Apple devices that I can think of. I don't think it's unreasonable to assume that there are other households just like ours but with Android devices instead.
---
ETA:
FWIW, a few months ago, Stephanie Cuthbertson, Android product manager, stated [2]:
> “Today there are over 2.5 billion active Android devices.”
Interesting stats. thank you for taking the time to research this. I do still have a few potential discrepancies however:
* Not all Android devices are ARM. However it's fair to say the x86 builds of Android are the exception so unlikely to affect the figures in any meaningful way
* Cuthbertson's figure is a sales pitch and hasn't been independently verified. Companies often inflate their figures to sound good (like when Apple included MacBook sales as part of their iPhone and iPad figures). Cuthbertson's figures do seem high (based on the napkin maths I presented earlier but also how Android has been growing faster than the growth of the population and smart phone market), so I'd be interested to know what Cuthbertson defines as "active". If someone upgrades their phone and sticks the old one in the draw, is it still classed as "active" for 1 month? 3 months? 12 months? Is it ever deprecated from the "active" list even though it's technically not in use any longer? If that's the case, we are back to my earlier point that deprecated Linux servers should also be in scope.
* Lastly not all Linux servers are sold as servers. There's quite a few examples of this:
1) Some of the larger hosting providers are known to build their own servers,
2) Some smaller or medium sized companies are known to buy second hand hardware for on-prem gear
3) ditto regarding hobbyists and home labs
4) It's not uncommon for desktops to be provisioned as makeshift Linux servers when requirements don't demand a rack-mountable enterprise solution
5) Also Linux doesn't have to be running bare-metal to be running an AMD64 kernel. There's plenty of instances of virtual machines in the world. Getting accurate figures of running Linux VPSs et al would prove impossible
6) Not all Linux AMD64 instances will be traditional servers. eg Elemental build their own Linux-based machines for transcoding. These wont be off the shell servers either. Then you have all manor of other black boxes out there from set top boxes, networking hardware, etc. Many of which wouldn't be AMD64 but many also will
7) Lets also not forget desktop Linux :)
Once you account for all of these edge cases I think non-AMD64/Android and AMD64/Linux become a lot more comparable. So I'd still be very surprised if non-AMD64/Android does outnumber AMD64/Linux by an order of magnitude.
Ultimately this an impossible argument to prove either way. However I think we do all agree on the overall point that both Android and Linux (in the more general sense) are hugely successful these days -- irrespective of their success relative to each other.
Looks like this is 64-bit but big endian. Weird choice when a) POWER has gone little-endian and b) this a system whose form factor implies running a Web browser and the Web requires little-endian ArrayBuffer behavior these days, so not running on a natively little-endian CPU seems inefficient.
I will be very interested in this when they have a "give money, get laptop" situation set up. I'm glad to see more open hardware and software in the wild.
But you'll have to excuse my skepticism as long as they need to run a fundraiser to get even the basic product together, let alone getting said product to market at a reasonable price for what it is.
I knew a number of companies that had a Waterloo moments after very successful kickstarter campaigns with PCs and smarthones.
Seeing a company making $1m+ on kickstarter, successfully delivering, and then committing big to mass manufacturing only to see single digit orders per day is something I see often in Shenzhen
Oh, certainly. But when it comes to advocating for free software (and free hardware to run it on), the end line is nothing less than the end of proprietary software. I'm not worried about reaching the end goal today, just taking a stride. My feeling is that if they can get to a situation where for, say, $200USD (or thereabouts), I can purchase their hardware with free software loaded on it and be relatively confident that it will arrive in working order, then I'm a happy camper. And I'll stand by that even if they can't remain in business after that point; because I will have gotten the machine I paid for.
Until I can exchange currency for goods, it's just vaporware with an ideal attached.
Yes, the fundraising campaign is for engineering work for a PPC motherboard for an existing laptop chassis.
I would also prefer sending them money in exchange for a physical product, but they're not at that point yet. They're asking for €24,000 which honestly seems a little low to cover the engineering work for an almost completely new laptop MB.
The only thing with that is usually 1 PCB is 24,000, but then 10 PCBs are 25,000 (i.e. making more is a lot cheaper than the first). If they have an existing chassis, than I would assume actually delivering a laptop isn't that difficult (famous last words, I understand).
>If they have an existing chassis, than I would assume actually delivering a laptop isn't that difficult (famous last words, I understand).
From what I can tell there are three distinct groups involved:
1) Slimbook -- an existing small laptop vendor. I'm not sure if they have an active engineering role with their amd64 motherboards or if they're more of an integrator, but I believe ~~they do the engineering for their laptop chassis (unlike some other linux laptop "manufacturers" who sell rebranded Clevo notebooks)~~. Edit: It appears that the Slimbook laptops are likely also rebranded Clevo PCs. That's pretty disappointing.
2) ACube Systems -- an existing PowerPC board designer / vendor, whose engineers will do the actual work under contract(?) from Power Progress Community.
3) Power Progress Community -- PowerPC enthusiasts, the group soliciting donations, and writing the specs. It seems they plan to function as an integrator using Slimbook chassis and Acube Systems motherboards.
All that is to say that I don't think the engineers working on the PPC board are the same ones who did the amd64 one.
PowerPCs have configurable endianness in the MSR register, but boot into big endian mode by default. macOS used it in big endian mode. Linux I can't speak to but believe you can pick based on kernel build config. As for IBM's OS' or the ones running on consoles, I can't speak to that.
The interesting part is that the motherboard also needs to support the specific endianness chosen, and when running in little-endian mode, it needs to perform a 64-bit byte swap on all data going in or out [1].
Linux gained support for little endian on IBM Power server CPUs in late 2013, in the lead-up to the release of the POWER8, where LE became the officially recommended option for running Linux. As you say, it's selectable at build time.
The PowerPC instruction set is ideal for emulating other instruction sets, since has byte swap instructions, and the delightful rlwinm instruction, and you could shift and mask for free with many instructions, which is great for decoding opcodes.
Anybody remember Connectix SpeedDoubler for PowerPC Macs? MacOS could emulate old 68K apps correctly but slowly, but Connectix SpeedDoubler recompiled 68K to PPC instructions on the fly! And it flew!
At Interval we were running 68k Mac Common Lisp with Connectix Speed Double on PowerPC Macs, and it would compile huge piles of Lisp code into 68k instructions, then when you ran it, Connectix Speed Doubler would compile that into PPC instructions to execute, and it actually worked quite well!
>On systems with PowerPC processors, Speed Doubler provides faster 68k emulation. When Speed Doubler was first released a few years ago, this was a very important feature, as there were still many popular applications which were not PowerPC native; nowadays, not many people use non-native software. Nevertheless, we dug up an old copy of MacDraw Pro, and were quite impressed with the results. Overall, performance was much improved. For example, launching the program took just 5 seconds, compared with 13 seconds without SD8 installed.
>The Mac OS's emulator translates every instruction each time, while Speed Doubler 8 compiles it the first time, so it can be executed immediately on subsequent times because it has already been translated. This technique, called dynamic recompiling, is responsible for SD8's greatly improved emulation.
>Faster Than a Speeding Power Mac — The final component in the Speed Doubler suite is the PowerPC Speed Emulator, and this component is what earns Speed Doubler its name. One of the weak points of a Power Mac is that it must run in the slower emulation mode when working with 68K-based software. Apple took some heat earlier this year for improving the Power Mac 68K emulator for the PowerPC 604-based Macs and not improving emulation in first-generation Power Macs. Well, fret no more. Not only does Speed Emulator improve the speed of your Power Mac when running 68K applications, it’s reputed to be 30 percent faster than Apple’s improved emulator! I’ve noticed a dramatic improvement of at least 50-75 percent over the week I’ve used it. Speed Emulator won’t improve the performance of native software – since native software already takes full advantage of the PowerPC chip – but remember that significant portions of the Mac OS are still non-native and Speed Doubler improves performance in those areas. Of course, Speed Emulator only works with Power Macs and is of no use on 68K-based machines, but Speed Doubler works on any Power Mac, not just Apple’s latest crop.
There was also Connectix RAM Doubler, which compressed stale pages, and even if it didn't literally "double" your RAM, it certainly helped.
>First up—check out this piece I wrote a quarter century ago from Macworld Expo San Francisco: “RAM Doubler” (10 January 1994). Developed by Connectix, RAM Doubler was one of the most magical utilities of the early days of the Macintosh. As its name suggested, RAM Doubler promised to double the amount of usable RAM in your Mac, and amazingly, it generally delivered.
>RAM Doubler is a single small extension that literally doubles your RAM. It’s not guessing at a 2:1 compression ratio, like Salient’s AutoDoubler and DiskDoubler (now owned by Symantec) – you actually see your total memory being twice your built-in memory. Since RAM Doubler is an extension, there are no controls, no configuration. You just install it and it doubles the amount of application RAM you have available.
At the time, MacOS on PowerPCs was fast but flakey, with no protection. So the tiniest little bug in a C program would freeze the machine, and it took ages to reboot, and even longer to get back into the flow of what you were doing when you made a little typo in your C code.
In terms of sheer productivity, it was well worth the cost of the emulation layer to program in a safe language like Mac Common Lisp that didn't crash the system all the time.
What I really wanted was Connectix Reboot Halfer, since that would have saved me even more time if every other reboot were free!
IBM has traditionally been a big-endian shop - mainframes are BE, AIX and IBM i on Power are BE. The Motorola 68K, which Apple was using before switching to PowerPC, was also BE.
LE support was in the original PowerPC chips from the 90s, and was used to support the Windows NT port that existed until NT4. Then switchable endianness disappeared for a while, and finally came back in POWER8 when IBM decided it wanted to expand the market for Power and that LE was helpful because it makes porting easier and is more familiar to x86 programmers.
It doesn't, AFAIK, have any overhead - remember that byte swapping can be done in combinational logic.
combinatorial logic... I guess byte order is just about which order you connect the wires between two components, and then it's free modulo "wire" length. That's my circuit board model of it, then.
I honestly have no idea haha. I speculate big machines dealing with legacy data or code not expecting big endian have an escape hatch that doesn't involve a complete rewrite.
Open Firmware Forth Code may be compiled into FCode, a bytecode which is independent of computer architecture details such as the instruction set and memory hierarchy. A PCI card may include a program, compiled to FCode, which runs on any Open Firmware system. In this way, it can provide platform-independent boot-time diagnostics, configuration code, and device drivers. FCode is also very compact, so that a disk driver may require only one or two kilobytes. Therefore, many of the same I/O cards can be used on Sun systems and Macintoshes that used Open Firmware. FCode implements ANS Forth and a subset of the Open Firmware library.
That same Open Firmware Forth system [1], which was developed by Mitch Bradley [2], was not only in the PowerPC Mac bios, but it was originally used for the SparcStation boot roms, and eventually in the OLPC, and it was even an IEEE Standard 1275-1994!
In fact: the Open Firmware boot loader and plug-in card firmware interface technology, commonly used by both Sun and Apple, is the only firmware standard in existence to have its own theme song [3] !!!
: OpenFirmwareSong ( - )
\ By Mitch Bradley.
\ Sung to the tune of "The Flintstones".
𝄞
." Firmware" cr
." Open Firmware" cr
." It's the appropriate technology," cr
." Features" cr
." FCode booting" cr
." Hierarchical DevInfo tree." cr
." Hack Forth" cr
." Using Emacs on the keys," cr
." Save in" cr
." NVRAM if you please." cr
𝄒 cr
." With your" cr
." Open Firmware" cr
." You can fix the bugs in no time" cr
." Bring the kernel up in no time" cr
." We'll have an FCode time!" cr
𝄒 cr
\ Thank you and good night!
reboot
;
Everyone here has made a bunch of great points about this hardware, and massive props to the creators, and to IBM for open-sourcing the CPU. In light of that, this comment might sound a bit "shallow Hal", but... looking at the Slimbook's "Eclipse" case... nothing about that screams "slim".
I'm not sure about power PC, but about 15 years ago I was working on a MIPS based desktop linux system, and there was no way to get adobe flash to run on it, which at the time was a big deal.
Could they have similar issues with media stuff (netflix, hulu etc) on a device like this?
I think Google's Widevine (which is used for a lot of these DRM'd streams) is only available for Chrome. I think we'd need Google to provide a Chrome for PPC binary, which would require them to bundle a WideVine for PPC binary.
Hmm, I wonder if this will be able to run AmigaOS natively.
I've played with Aros a bit but I would love an excuse to play with "real" Amiga running natively, but the current PowerPC offerings for Amiga are obscenely overpriced.
If only IBM had come out with a PowerPC Thinkpad that ran MacOS in 1995 like IBM and Apple jointly promised was the whole point of CHRP: the Common Hardware Reference Platform. But nooooo, they thought all the cool kids wanted to run WARP, aka OS/2, aka "Half an Operating System".
The great thing about the Thinkpads of 24 years ago was that they were so well built and modular and user serviceable that many of them would still be working even now. They were so much more solid and dependable than anything Apple ever produced in their entire history, and especially their shitty PowerPC laptops of that time period. It would have been the perfect Powerbook, but from IBM. But no, IBM and Apple couldn't stomach running Apple software, and Apple couldn't stomach their software running on robust reliable repairable hardware.
>Common Hardware Reference Platform (CHRP) is a standard system architecture for PowerPC-based computer systems published jointly by IBM and Apple in 1995. Like its predecessor PReP, it was conceptualized as a design to allow various operating systems to run on an industry standard hardware platform, and specified the use of Open Firmware and RTAS for machine abstraction purposes. Unlike PReP, CHRP incorporated elements of the Power Macintosh architecture and was intended to support the classic Mac OS and NetWare, in addition to the four operating systems that had been ported to PReP at the time (Windows NT, OS/2, Solaris, and AIX).
>Open Firmware, or OpenBoot in Sun Microsystems parlance, is a standard defining the interfaces of a computer firmware system, formerly endorsed by the Institute of Electrical and Electronics Engineers (IEEE). It originated at Sun, and has been used by Sun, Apple, IBM, ARM and most other non-x86 PCI chipset vendors. Open Firmware allows the system to load platform-independent drivers directly from the PCI card, improving compatibility.
>The name stands for "Operating System/2", because it was introduced as part of the same generation change release as IBM's "Personal System/2 (PS/2)" line of second-generation personal computers.
IBM should have used this for the OS/2 theme song:
>At the time, IBM was making CHRP (Common Hardware Reference Platform) PowerPC Thinkpads, which nobody could think of anything to do with because all they did was run OS/2, when everybody actually wanted them to run MacOS (but IBM refused to admit that was a good idea). That would have been the best of both worlds, back when Apple and IBM were in bed together (i.e. Kaleida, Taligent).
>CHRP was the Common Hardware Reference Platform for the PowerPC, which IBM and Apple collaborated on. IBM made a CHRP PowerPC Thinkpad that ran OS/2, but out of pride refused to sell one that ran MacOS, which kind of missed the whole point of CHRP. IBM just couldn't imagine why anyone would want to run anything but OS/2 on them.
>I would have loved to have a MacOS powerbook running on wonderful Thinkpad hardware, because Apple's laptop hardware was pretty crappy at the time. It would have been the best of both worlds, but it was never to be.
Since POWER9 only exists in the server / HEDT sphere, I doubt this will be a modern POWER9 chip. Maybe something like a NXP-chip, which would still be interesting. Something on the scale of a Chromebook maybe?
If binaries were compatible with the Talos II POWER9 HEDT / Server, then there is still a good use of this laptop. To serve as a portable development platform, much like Intel Atom can serve as a portable development platform for Intel Xeons.
Depends on a lot of details however. Honestly, its probably more important to rack-up a POWER9 Talos II and just SSH into it every once in a while... modern cloud-based services makes this sort of thing much easier.
----------
EDIT: Site finally worked for me. NXP T2080 chip, 4-core / 8-thread 28nm class chip. e6500 core, which is some form of PowerPC for sure... 128-bit vector units (Altivec). 32kB L1 d$ and 32kB L1 I$, 2MB L2$ for the whole chip.
This is older-tech for sure, definitely "Chromebook" level of tech, maybe a touch weaker even.
EDIT2: I think there's something to be said about an "open" design, where the schematics are available for the community to use and extend. The NXP T2080 has good GPIO pins and connectivity, so there's a chance that this laptop will be easier to interface with electronically than other devices. Guys over at hackaday probably would love something like this. https://gitlab.com/oshw-powerpc-notebook/powerpc-laptop-mobo...