Apple's M1

It’s here and here and you can buy it now.

…those performance numbers look ridiculously good for that ARM-based chip…but let’s see some indepedent benchmarks soon…could be the start of the end of x86, but I guess Apple would never “open” it for the “public” ;-)

Edit: Some interesting outlook from AnandTech here …with a conclusion “If Apple’s performance trajectory continues at this pace, the x86 performance crown might never be regained.”

Really nice. Now I can replace my MacPro 2009 by a MacMini M1.

First reviews on the M1 are up, e.g. here

The Apple M1’s stellar performance really shouldn’t come as a surprise to us, Apple has an ARM architecture licence and it bought the company PA-Semi to work on it’s ARM designs – a company set up by the lead designer of the DEC Alpha and of course the StrongARM!

Thanks for the hint, David. Didn’t know about PA-Semi and Daniel Dobberpuhl, very interesting person and history there.

After diving deeper in that M1 review it’s really marvelous what those guys pulled of within Apple. Also on the software side with Rosetta2. In regard to x86 competition I wonder how far they can get. For the moment it looks like they focused on best performace/power ratio. It’s yet to be seen if that massiv parallel-instruction-port design can be pushed to more than 4 performance cores and clock rates at 4 to 5 GHz compared to the 3.2 Ghz which it seems to be limited.

It really pushes the competition and also actually software development for native ARM apps. I guess we should see native ARM code apps from almost all essential software availbale for Apple’s within the next year.

I keep my fingers crossed Linux will come up on that mac mini by some hack and we could run the RISC OS port there :-)

I hope Apple get this transition to go more smoothly than the previous CPU transition. Our company had a raft of Macs, which never raised any problems. Then two things came simultaneuously – a new IT manager who hadn’t used Macs, and the new OS and occasional crashes. Our users weren’t used to machines crashing, so called IT every time. The managers reaction- scrap this rubbish and buy PCs. Within a year we went from one person doing Mac support half time, to 4 people doing PC support full time. We never looked forward after that.

By now it looks it will be kind of “bumpy”. As seen in the mobile world software developement lacks behind hardware many times. Seems the same here.

Today they announced a ARM-compiled Chrome…now they took it back due to crashing. I also read Photoshop ARM is available, but lacks certin features…as you said that if they don’t get that right in time and they very much depend on third party here except the Rosetta 2 “versions”…some people might wait or put it back on the shelve…

yeah not stable yet guys, as I mentioned in other topics here:

• XCode fails to install correctly yet, the main code installs and gets converted to ARM64, however its plugins don’t, so when I try to start up XCode I get a fatal error and it quits

• In general all applications with “external” plugins loaded via custom loaders seems to be having problems with Rosetta 2 because it doesn’t always detect they are plugins and so doesn’t convert them correctly OR the API fails to work after conversion

• There seems to be some issue on some native ARM64 apps as well as reported above but it’s a bit of a hit and miss there right now.

In my case I still need to update to latest Big Sur so I may be a bit behind…

Not having £700 lying about, it’s all a bit academic for me…

yeah not stable yet

Looks like Marketing won the battle with QA at Cupertino….

Looks like Marketing won the battle with QA at Cupertino….

QA? Isn’t that prefab hut tent round the back of the complex?
I was under the impression that, like MS and various other large businesses, they left QA and beta testing to the paying customer sucker.

Not having a working XCode seems a bit of an own goal!

Looks like Marketing won the battle with QA at Cupertino….

Yup, since Steve Jobs died, Apple had a free-fall in quality tbh… but that’s what we have on the market right now, unless you want to go for alternative and native Linux companies like System76, which I like, but not for every users I guess…

@ Stuart

Not having a working XCode seems a bit of an own goal!

LOL yeah, but now we need to explain them what an “own goal” in football is looool :D

LOL yeah, but now we need to explain them what an “own goal” in football is looool :D

Try explaining that what Americans call “Football” is a modified Rugby Football, which in either of the Union or League variants does not involve wearing body armour so collisions hurt
However, since only a thug¹ would attack someone without the ball in hand it’s OK.

¹ Association Football (Soccer) is said to be a game for gentlemen played by thugs, while Rugby is a game for thugs played by gentlemen.

but now we need to explain them what an “own goal” in football is

Easy. Your guy picks up the ball and runs the wrong way.

or “Your guy is a Rxxxy and his team are agents from CHIIINAAA” MAGA

Easy. Your guy picks up the ball and runs the wrong way.

or “Your guy is a Rxxxy and his team are agents from CHIIINAAA” MAGA

looool :D

@Paolo: As I would be super interested on coding on that M1 platform: Is there any C-compiler and or seperate inline Assembler (or stand alone…) available to start coding on that under MacOS that let you set up some linear frame buffer and get some pixels on the screen as a start ?

@ Kuemmel

As I would be super interested on coding on that M1 platform:

AFAIK, for coding in C, at this time, there is only Apple XCode, the M1 is too new and not yet supported in GCC.

As soon as GCC will support it you can use GCC under XCode and that means you’ll have access to GCC GASM for the Assembler and GCC C for the C.

For the framebuffer part of your question: So macOS historically offered the IOFrameBuffer class which is exactly what you seem to want, but IOFramebuffer has been deprecated by a while, so I am not 100% sure if it’s still available…

IOFramebuffer had methods like IOBlitMemory, IOBlitScanLines, IOBlitOperation that are the low level you seem to be seeking for…

However in modern computing usually you should use a user-space API (btw this is why the whole long discussion on RISC OS future as a Desktop OS vs a Hackable OS…) for example on Linux you would use DRM for this and on macOS is Metal.

Now Metal works in a different way, for instance on Metal you have a programming model more similar to Client/Server where your C code makes a request to the “Server” (the GPU) etc… And what your request looks like is a “Command Queue” (a pipeline basically) where you add all your requests in a command buffer and then you get your responses. This because the shader code used is in the GPU and not anymore in the OS per-se or in your program…

Sorry for the ultra condensed explanation, I just didn’t want to move away from the main topic too much…

Hope this helps somehow

Thanks Paolo for that insight…so it seems Metal is similar to Open GL…I toyed arround with the later one on some online shader coding webpages, but never did any stand alone app on x86.

Seems quite hard or lets say lots of obfuscated code lines needed just to get one pixel on the screen with Metal. All the overhead drives me nuts when I check out a new platform ;-) But on the other hand…even if the IOFrameBuffer is deprecated…but may be I’m wrong I can’t believe a normal application on MacOS would always need Metal as an API. Wouldn’t there be another framework/API where you can lets say set up a window and put some pixels inside ?

Because with my very limited knowledge of OpenGL I would say you can’t do something like pixel perfect there because everything would be kind of mapped/sized to a kind of framebuffer (fragColor).

@ Kuemmel

but may be I’m wrong I can’t believe a normal application on MacOS would always need Metal as an API.

This is different lol, so to write a pixel or a line in Cocoa for example, without using Metal or OpenGL, you would use something like the NSBezierPath which allows you to access an API similar to RISC OS Draw for example.

However working with cocoa etc… is not accessing directly the framebuffer… so may I ask you exactly which type of application do you want to write?

For instance:

• an old-school 2D game will need access to Metal/OpenGL these days on macOS, unless you want to work out something very custom that may give you more headaches than results…
• a “WIMP” application needs to use Cocoa and then, obviously whatever graphic API you fancy depending on the type of “graphic” you want

The “obfuscated” code is something we deal with by quite long time now, it was introduced with the concept of GPU when computing moved away from the concept of Video Controller. It’s the meaning of the word Processing in the acronym GPU. In other words modern GPUs also execute code, the so called shaders and their own pipeline.

So to have an accessible framebuffer on a modern OS you could add it yourself (it’s always a buffer in the end) and then send it for rendering to the GPU by following the GPU pipeline. For example you could use the bitmap API.

For the specifics of using plain C instead of ObjC or swift, you shoul dmake sure you include the right objC libraries to your C app:

#include <objc/objc.h>
#include <objc/runtime.h>
#include <objc/message.h>
#include <objc/NSObjCRuntime.h>
#include <OpenGL/gl.h>

Then you probably want to include the cocoa headers:

#include <CoreGraphics/CGBase.h>
#include <CoreGraphics/CGGeometry.h>

And make sure you initialise things correctly:

typedef CGPoint NSPoint;

extern id NSApp;
extern id const NSDefaultRunLoopMode;

Then the ARM64 checks/defs

#ifdef __arm64__
#define abi_objc_msgSend_stret objc_msgSend

etc…

#endif

And then your C code in which you’ll have to use classes from objC.

Not sure if this would work, still need to test pure C on Big Sur and on ARM, but it’s a starting point, also don’t forget that Apple has a pretty good developers site and community, which is probably the best place to ask for help/info…

btw… quick update, XCode works fine in Big Sur 11.0.1, now updating to Big Sur 11.1…

Ok, thanks for the code snippets, I’m not to familiar with anything than plain C from DOS times, but in the end I guess it’s just a framework you have to set up some time and live with it.

Regarding what app I want to code…I’m mostly into old-school-demo and intro coding, so some graphic thingy running full screen with sound or not, while not using the GPU, just calculating the pixels “by hand”…So in that sense it’s similar to old-school 2d games.

Regarding that I would think also Metal wouldn’t let you do pixel exact stuff ? When I think of Open GL ES the coordinates of the pixels on screen are floats between 0.0 and 1.0 refering to whatever screen resolution. So per se it can’t be pixel exact. But that Cocoa looks more like that…may be just here is the question if that API is fast enough for demo/intro coding regarding pixel access. I remember Java/Javascript where you could asign an array in memory and copy or make it the source of a framebuffer/windowbuffer and it worked quite well.

Keep me updated on your findings with the latest XCode/Big Sur…so we could learn coding 64Bit ARM assembler before it will be there on RISC OS ;-)

@ Kuemmel

Ok, thanks for the code snippets,

no problem :)

I’m not to familiar with anything than plain C from DOS times

C is good enough for almost everything! :D – However macOS, as people know it nowadays, is a son of NeXt Step OS and Object orientated API, so the closer you can get to C is via objective C libraries, so coding in pure C on macOS can be a bit cumbersome …

Regarding what app I want to code…I’m mostly into old-school-demo and intro coding, so some graphic thingy running full screen with sound or not, while not using the GPU, just calculating the pixels “by hand”…So in that sense it’s similar to old-school 2d games.

Then you are already on the right OS… RISC OS :D for demo coding it’s really good, because you do not have the limitations the Amiga has for example and you have new fast Hardware as well as VFP and NEON which can really make your demos outstanding by any standards and if you want to increase code density in your demo you can use thumb instructions, so why would you want to suffer on macOS ??? macOS is designed as a daily desktop system, so it tries to protect a lot of aspects of the hardware and makes it hard to code in the style you want to use.

Regarding that I would think also Metal wouldn’t let you do pixel exact stuff ?

So both OpenGL and Metal (as well as DirectX for windows) are designed to squeeze performance from the underlining hardware which in the case of graphics is the GPU, you in the other hard want to use the CPU for most of the work, although I would argue that on the Amiga we started to use HW acceleration before OpenGL/Metal/DirectX were a thing, so to be frank hw acceleration is also traditional in the demo scene… On the Archimedes things were different but that because it had an impressive memory bandwidth for the time and was able to move pixels faster than the Amiga HW acceleration (and that also because the Amiga chip memory was a bottle neck, but this is another story for another place…)

I remember Java/Javascript where you could asign an array in memory and copy or make it the source of a framebuffer/windowbuffer and it worked quite well.

Sure, here is an example of what you are asking for in C (again requires cocoa on macOS):

https://github.com/emoon/minifb

Keep me updated on your findings with the latest XCode/Big Sur…so we could learn coding 64Bit ARM assembler before it will be there on RISC OS ;-)

Sure, but you do not need a mac to learn 64bit ARM assembly, just install a 64bit Linux distro for ARM on a RPi 4 and you’ll have all you need already. Apple is not keen to allow people to use Assembler, so probably the M1 will be covered by GCC GASM in the future and/or you can already use the ARM Holdings developer suite and Keil (if you are keen to embedded developments), more info ere:

https://developer.arm.com/documentation/dui0068/b/

Anyway good luck with your projects and have fun! :)