Premiär! Fyndchans i SweClockers Månadens Drop

Bloomberg: "Apples Macbook med ARM-processor får 12 kärnor"

Permalänk
Skrivet av bimbim:

Jag testade att installera Catalina (senaste MacOS) på en Mac Mini från 2009 med Core 2 Duo(!) och sjukt nog så flöt OS:et på bra.

Cool! Trodde inte att det fanns grafikdrivare för GeForce 9400M i MacOS Catalina. Eller har du ”trixat in dem” i efterhand? 🤔 Dosdude1's Catalina Patcher kanske?

Visa signatur

• Fractal Design North | ASUS ROG Strix B650E-F | Ryzen 7 7800X3D | Radeon RX 7900 GRE | 64 GB RAM | Windows 11
• Mac Pro (Mid 2010) | 6-Core Intel Xeon ”Westmere” | Radeon RX 5700 XT | 32 GB RAM | macOS 12 Monterey | Windows 10
• MacBook Pro 14" | M2 Max | 96 GB RAM | macOS 14 Sonoma

Permalänk
Datavetare
Skrivet av mpat:

Bärbara gick från G4 - 744x eller 745x - till Core Duo, vilket var Yonah, eller på ren svenska andra generationens Pentium M fast tvåkärning med SSE3 och NX-biten. Men...

Det är skillnad på PPC 7400/7410 och 7440/7450. Apple kallade bägge för G4, men de är inte speciellt lika. I entusiast-kretsar kallades 7450 för G4e, även om Apple aldrig sa det. G4e är definitivt inte in-order. Rent tekniskt gäller det också lite äldre PPC designer, där de har små ”reservation stations” som gör att instruktioner kan exekveras utan att följa programmets ordning, men det är en ytterligt begränsad omfattning.

En helt OK genomgång av G4e finns här:

https://arstechnica.com/features/2001/05/p4andg4e/

Imacarna körde G5 de också. Jag hade en av dem, som tyvärr dog. G5 var en design med väldigt hög latens till huvudminnet. I en POWER4 täcks det problemet genom att den hade en för sin tid enorm cache (16MB, tror jag, men jag kan minnas fel). Den cachen hade Apple inte råd med, och då gick det som det gick med heltalsprestandan. Flyttal var den enorm på, däremot.

Du har helt rätt, PowerPC G4e är en hyfsad uppdatering från G4 (har själv bara kört just G4, har kvar en MacMini G4). Men det är en väldigt begränsad form av out-of-order körning som var möjlig i G4e, mindre avancerad än PPro (färre instruktioner kan vara "in-flight").

Oavsett, huvudpoängen kvarstår: PowerPC är inte en odelat mer effektiv ISA jämfört med x86, i framförallt heltal är x86 minst lika effekt och det är långt viktigaste egenskap. Vidare verkar inte ens G5 (som är mer avancerad än G4e) matcha Core Duo i "IPC" (mängd utfört arbete i samma program vid samma frekvens, går inte riktigt att direkt jämföra IPC mellan två olika ISA).

Så när Apple bytte till x86 fick de på nästan alla tänkbara fall en snabbare CPU, det primärt p.g.a. mer avancerad mikroarkitektur (vilket var min huvudpoäng).

För Aarch64 är ISA i princip rakt av en lika bra eller bättre ISA jämfört med x86_64. Det syns bl.a. i Cortex A77 som utför mer per klockcykel när den kör samma program som t.ex. Zen2/Skylake. Det trots att A77 inte riktigt har lika stort out-of-order fönster och flera andra mikroarkitekturrelaterade saker är inte fullt på Zen2/Skylake nivå. På samma TSMC 7nm process är en Cortex A77 kärna ungefär en tredjedel så stor som Zen2!!!

D.v.s. om det nu blir ett byte är det inte bara en byte till en mer kapabel mikroarkitektur (Apples A13 design är bredare än både Skylake och Zen2), man får också en ISA som är bättre. PowerPC -> x86 kan mycket väl ha varit ett större steg när det hände, men det säger bara än mer hur stort övertag Intel hade i mikroarkitektur då man inte hade någon direkt ISA fördel (just ISA är delvis förklaringen till varför PowerPC klarade sig bättre i just flyttal, men den delen har man nu fixat på x86 genom att x86_64 skrotat x87 och kör med variant av SSE/AVX för flyttal).

En sak har dock inte ändras: det är primärt för heltalsberäkningar som Aarch64 är väsentligt bättre än x86_64. Så inte alls säkert att eventuell Cinebench på Aarch64 kommer stå sig superväl mot x86. Men finns en Cinebench på MacOS? Kanske är ett icke-problem

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare
Skrivet av anon214822:

Är det problem med minneskonsistens som hindrar Intel att bygga processorer med både x86 och Aarch64-kärnor?

Nu kanske Intel av uppenbara skäl inte är intresserade av att kränga Aarch64 men man hade ju kunnat hitta på en Intel-specifik arkitektur som inte dras med allt det gamla bagaget samtidigt som det fortfarande gick att köra den gamla koden på några x86-kärnor inuti CPUn.

Man hade migrerat över kundbasen till något bättre och samtidigt hängt av AMD.

Nej. Det som primärt hindrar, förutom att jag kan tänka mig licensproblem, är att mycket av de transistorer man idag slänger på att få upp farten på x86_64 är en kostnad som inte behövs med Aarch64.

Så en kombinerad x86_64 + Aarch64 skulle sakna flera av fördelarna med den senare alt. bli en väldigt långsam x86_64. I det senare fallet kan man ju nästan lika gärna köra "vanlig" emulering.

Både Intel och AMD lär vara rätt ointresserade att pusha Aarch64. Tidigare kanske de såg ARM som mer harmlösa, men med tanke på att t.ex. Amazon valt att bygga egna Aarch64 servers tror jag Intel/AMD vill göra allt för att bromsa migration från x86. Ingen annan kan göra x86 CPUer som är relevanta prestandamässigt. Går världen till Aarch64 får de både betala licenspengar till ARM och blir en i mängden.

Om något tror jag Intel då långt hellre hjälper RISC-V. Finns ryktet om att Intel redan har RISC-V modeller i labben. Men samma där, de vill inte pusha något annat än x86 så länge de inte behöver, för även med RISC-V blir de en i mängden (fast man slipper betala licenspengar till någon).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Vet inte om det är klokt att dra upp gamla strider om PPC mot x86, men... Förutom flyttalsgrejorna är PPC mycket lättare att avkoda. De transistorerna kunde istället användas till cache... vilket behövdes, för x86 lyckas i medel packa in fler instruktioner i samma i-cache. Den stora skillnaden mellan dem på den tiden var att PPro var en mycket lyckad design och Intel lyckades utnyttja sitt försprång inom processtekniken till att krama ur precis allt som fanns. På PPC-sidan var det lite upp och ner. 603 var ”OK” (mycket lik Pentium till sin prestanda-profil). 604 var bra - riktigt bra på sin tid - men fick egentligen ingen uppföljare. 750, ”G3”, var en uppdatering av 603 och var väl OK när den kom. IBM lyckades ju skrämma upp klockfrekvensen på den rätt bra i slutänden. 7400 måste sägas vara en miss, eftersom Motorola aldrig fick ordning på den klockfrekvensen. 7450 var helt OK när den kom, men sen köpte Intel över hela utvecklingsgruppen bakom 7500 så att Motorola lade ner den (och stämde Intel, och vann), och då var det ingen kvar som ville göra en desktop-processor. G5 var ju en server-processor som modifierats lite lätt.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av Yoshman:

En sak har dock inte ändras: det är primärt för heltalsberäkningar som Aarch64 är väsentligt bättre än x86_64. Så inte alls säkert att eventuell Cinebench på Aarch64 kommer stå sig superväl mot x86. Men finns en Cinebench på MacOS? Kanske är ett icke-problem

Nu var du väl iof en aningen ironisk, men klart det finns. C4d har ju en stor användarbas på MacOS, även om den säkerligen minskat på senare år.

Permalänk
Datavetare
Skrivet av sKRUVARN:

Nu var du väl iof en aningen ironisk, men klart det finns. C4d har ju en stor användarbas på MacOS, även om den säkerligen minskat på senare år.

Och om man bryr sig om prestanda där gäller ju samma sak som för alla andra: trenden för den typen av arbete går allt mer mot GPGPU. Det betyder att CPU-delen kvittar.

Vill man köra flyttalsintensiva saker på Aarch64 ska man titta på SCE (Scalable Vector Extensions)

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Inaktiv
Skrivet av Yoshman:

Nej. Det som primärt hindrar, förutom att jag kan tänka mig licensproblem, är att mycket av de transistorer man idag slänger på att få upp farten på x86_64 är en kostnad som inte behövs med Aarch64.

Så en kombinerad x86_64 + Aarch64 skulle sakna flera av fördelarna med den senare alt. bli en väldigt långsam x86_64. I det senare fallet kan man ju nästan lika gärna köra "vanlig" emulering.

Både Intel och AMD lär vara rätt ointresserade att pusha Aarch64. Tidigare kanske de såg ARM som mer harmlösa, men med tanke på att t.ex. Amazon valt att bygga egna Aarch64 servers tror jag Intel/AMD vill göra allt för att bromsa migration från x86. Ingen annan kan göra x86 CPUer som är relevanta prestandamässigt. Går världen till Aarch64 får de både betala licenspengar till ARM och blir en i mängden.

Om något tror jag Intel då långt hellre hjälper RISC-V. Finns ryktet om att Intel redan har RISC-V modeller i labben. Men samma där, de vill inte pusha något annat än x86 så länge de inte behöver, för även med RISC-V blir de en i mängden (fast man slipper betala licenspengar till någon).

Du kanske missförstod mig. Jag tänkte mig alltså inte kärnor som klara bägge ISA utan typ 4 rena Aarch64-kärnor och 4 rena x86-kärnor på samma chip. Nu är Aarch64 bara ett exempel, naturligtvis skulle Intel göra något helt eget nytt. Låt oss säga 4 st x86 och 4 st x86++. Bygger du ett program för en sådan propp kan du välja vilken typ av kärna du vill köra på. Om nu x86++ är bättre så kommer så småningom en så stor andel av mjukvarorna att ha valt den och till slut kan man skippa x86 och bygga chip med bara x86++ (som då är fullt konkurrenskraftig med Aach64 eller rentav bättre). Intel behåller greppet om marknaden. Visst kostar det transistorer med en sådan här hybridlösning men det finns också en alternativkostnad när folk byter från x86 till Aarch64. Intel måste ju hitta på något om man vill bevara sin position.

Permalänk
Medlem

En annan intressant detalj som nämndes var att den nya ARM-macen skulle stödja USB-4.

Prestandamässigt finns det emellertid en detalj som är ack så viktig, men som inte nämndes. En Macbook i sedvanlig formfaktor kommer antagligen att levereras med fastlött DRAM. Och vid den aktuella tidpunkten lär det vara LPDDR5. Vilket i sin tur vid 128-bitars bred buss innebär en bandbredd till RAM på över 100GB/s nominellt, och med förbättringar i det praktiska utnyttjandet visavi DDR4. Så inte nog med att man kan räkna med väldigt god enkel- och flertrådad prestanda, CPUn lär bli matad av ett minnessystem som slår allting utom de bästa HEDT systemen på fingrarna. Och kanske t.o.m. dem, i synnerhet om Apple gör något oväntat och använder HBM istället för LPDDR. Den bristande flexibiliteten i möjliga minneskonfigurationer är ju business as usual i segmentet.

Permalänk
Medlem
Skrivet av Yoshman:

Både Intel och AMD lär vara rätt ointresserade att pusha Aarch64. Tidigare kanske de såg ARM som mer harmlösa, men med tanke på att t.ex. Amazon valt att bygga egna Aarch64 servers tror jag Intel/AMD vill göra allt för att bromsa migration från x86. Ingen annan kan göra x86 CPUer som är relevanta prestandamässigt. Går världen till Aarch64 får de både betala licenspengar till ARM och blir en i mängden.

Precis, AMD och Intel har allt att förlora på att tappa sitt duopol. Till exempel kan då en bitter konkurrent som Nvidia börja göra Windows CPU också.

Permalänk
Skrivet av EntropyQ3:

Det är inte för att Intel inte har försökt!
Jag kan dra mig till minnes åtminstone tre försök, i960, en "RISC" (se Yoshmans inlägg ovan) som funkade hyfsat bra, hamnade så småningom som embedded CPU i skrivare o dyl. i860, ett flyttalsmonster som var tänkt för desktop som ersättare till x86, men visade sig knepig att kompilera bra kod till. Och naturligtvis Itanium, deras 64-bitars dröm, som egentligen aldrig levererade där den skulle, såldes som FP stark processor tills den dog.

Det är en definitionsfråga hur man väljer att betrakta Larrabee.

Hur kommer det sig att Intel gissar jag är mycket större än ARM men inte kan komma på en vettig arkitektur men ARM lyckas?

Permalänk
Medlem
Skrivet av Yoshman:

Och om man bryr sig om prestanda där gäller ju samma sak som för alla andra: trenden för den typen av arbete går allt mer mot GPGPU. Det betyder att CPU-delen kvittar.

Vill man köra flyttalsintensiva saker på Aarch64 ska man titta på SCE (Scalable Vector Extensions)
https://www.youtube.com/watch?v=eXhlDt2SD8o

Yes, när vi på vår arbetsplats (som använder C4D) gick från Mac (soptunnor), så var det till stor del pga av Octane. Skillnaden var så enorm att det inte var den minsta protest om att gå till windows/pc från användarna.

Permalänk
Medlem
Skrivet av Yoshman:

Det är förvirrande för alla tror jag, finns tyvärr ännu en dimension i form av ARMs ISA versioner

Tidigare var det bara ISA-versionerna man behövde bry sig i. Du kanske sett ARMv6 och ARMv7, där den förra är vad första RPi hade stöd för och man har valt att stanna där i Raspbian-distron.

ISA-versionerna är en lite mer organiserad variant av det vi ser på x86 i form av nya instruktioner. Fram till och med ARMv7 fanns ju bara 32-bitars ARM, så instruktionsuppsättningen var alltid "ARM" och exakt vilka instruktioner som fanns tillgängliga dikterades av ISA-version.

Det blev rejält komplicerat med ARMv8...

ARMv8 fixade till så även 32-bitars ARM fick de förbättringar kring minnessynkronisering som Aarch64 berikades med. 32-bitars läget i ARMv8 är i praktiken en ren utökning av ARMv7, d.v.s. det är samma binära kodning på instruktionerna med samma antal register också så.

Men nog mycket p.g.a. att 32-bitars ARM och 64-bitars ARM verkligen är två separata instruktionsuppsättningar (helt inkompatibla binärkodningar) så ville ARM ha sätt att referera till de olika exekveringskontext som finns i 64-bitars läget. Möjligheten att köra 32-bitars program under en 64-bitars (Aarch64) kärna betecknas Aarch32.

Men Aarch32 är ett nytt påfund som just kom i samband med ARMv8, det är inte vad man kallar "vanlig" 32-bitars ARM-kod som används för ARMv7 och tidigare (där både program och OS-kärna är 32-bitars program).

Vill man bli ännu mer förvirrad finns ett till läge i 32-bitars ARM som kallas Thumb/Thumb2. Det är ännu mer kompakt jämfört med 32-bitars ARM, men har nackdelen att vara lite mer komplicerat att avkoda p.g.a. att instruktioner är 2 eller 4 bytes (de är alltid 4 bytes på "vanlig" 32-bitars ARM och Aarch64).

Ännu en anledning att droppa 32-bitarsstödet helt om du frågar mig. Kör man renodlad 64-bitars ARM är det enkelt, instruktionsuppsättningen är Aarch64 och benämns ibland också ARM64.

Tack för förklaringen. Jag tror att jag är med i matchen nu.

Permalänk
Medlem
Skrivet av Dinkefing:

Hur kommer det sig att Intel gissar jag är mycket större än ARM men inte kan komma på en vettig arkitektur men ARM lyckas?

En del av problemet är tveklöst bakåtkompatibilitet. Man får ge Intel credit för att de har gjorde ”clean slate” försök, men å andra sidan har de haft väldigt svårt just därför. Intel är otroligt starka på marknaden och har varit ännu starkare men att pressa igenom en helt ny proprietär lösning har i gengäld också visat sig oerhört svårt.
Ett annat problem har därför också varit att man haft olika ståndpunkter inom Intel - är det verkligen en god idé att försöka utmana sitt eget (nästan) monopol? Öppnar man inte bara därmed dörren för andra alternativ, om kunderna nu ändå måste överge sin gamla kodbas?
Så det har funnits falanger inom Intel som menat att man skapat öppningar för konkurrenter genom att sitta fast i bakåtkompatibilitet, samtidigt som en annan stark falang menat att det skulle skapa oacceptabla öppningar för konkurrens att tvinga kunderna att migrera alls. I slutändan tycks det senare ha dominerat de senare åren, och man har drivit en x86 everywhere policy, som med facit i hand i praktiken kostade dem hela den mobila marknaden, trots de enorma belopp de plöjde ner i den satsningen.

Permalänk
Inaktiv
Skrivet av Herr Kantarell:

Jag tror snarare "helt ok" prestanda och löjlig batteritid. Nu undrar jag om jag ska köpa en laptop i år eller vänta till nästa

Jag hoppas på både och! Om jag känner Apple rätt så gör dom hellre laptopen tunn som ett löv och lätt som en fjäder än att ge oss bra batteritid... men men!

Permalänk
Medlem

Tror det här kan bli riktigt bra på sikt med överlägsen batteritid.
Dock ska man nog kanske inte hoppa på det direkt när det släpps utan vänta tills det är lite mer moget.

Visa signatur

Ghost S1 || Asrock Phantom Gaming Z390 || 9900KF || Corsair 32GB@3400MHz CL16/1.45volt || Intel 660p 1gb || Corsair sf600 || RTX 4070 Inno3d 2x|| Asus PG279QM

Macbook pro 14 M1

Permalänk
Medlem
Skrivet av star-affinity:

Cool! Trodde inte att det fanns grafikdrivare för GeForce 9400M i MacOS Catalina. Eller har du ”trixat in dem” i efterhand? 🤔 Dosdude1's Catalina Patcher kanske?

Spot on. Dosdude1-patchen precis! Fungerar över förväntan bra på en gammal häck.

Visa signatur

Spelar du eller vill du spela Valheim? Joina vår dedikerade server och Discord. PM:a för inbjudan.

Permalänk
Medlem

ARM processor i nästa ipad vore välkommet

Permalänk

@Swedman18:
Vad har den nu då menar du?

Visa signatur

• Fractal Design North | ASUS ROG Strix B650E-F | Ryzen 7 7800X3D | Radeon RX 7900 GRE | 64 GB RAM | Windows 11
• Mac Pro (Mid 2010) | 6-Core Intel Xeon ”Westmere” | Radeon RX 5700 XT | 32 GB RAM | macOS 12 Monterey | Windows 10
• MacBook Pro 14" | M2 Max | 96 GB RAM | macOS 14 Sonoma

Permalänk
Medlem
Skrivet av DasIch:

MacOS är ingen "walled garden".

Det finns egentligen ingen teknisk begränsning som skulle hindra Apple från att göra MacOS till en "walled garden" i framtiden om de vill.
Det är samma kärna och stort sett samma subsystem i både MacOS som i iOS och iPadOS.

Visa signatur

För övrigt anser jag att tobak ska förbjudas.

Permalänk
Medlem
Skrivet av Findecanor:

Det finns egentligen ingen teknisk begränsning som skulle hindra Apple från att göra MacOS till en "walled garden" i framtiden om de vill.
Det är samma kärna och stort sett samma subsystem i både MacOS som i iOS och iPadOS.

Det finns ingen teknisk begränsning som hindrar något OS från att göras till en "walled garden".

Permalänk
Medlem
Skrivet av DasIch:

Det finns ingen teknisk begränsning som hindrar något OS från att göras till en "walled garden".

Märka ord! Det är skillnad mellan olika OS. Det skulle det vara en ganska liten förändring att stänga av att man kan installera från varsomhelst: funktionen finns redan men är bara avslagen.

Men förutom tekniken så finns det också en skillnad i kultur på Mac jämfört med andra plattformar.
Det är mycket samma utvecklare och programhus som på iOS som redan är stängd, och det finns en tradition av att "Apple vet bäst" som gör att jag tror att Mac-användare lättare skulle finna sig i en stängd plattform.

Visa signatur

För övrigt anser jag att tobak ska förbjudas.

Permalänk
Medlem
Skrivet av Findecanor:

Märka ord! Det är skillnad mellan olika OS. Det skulle det vara en ganska liten förändring att stänga av att man kan installera från varsomhelst: funktionen finns redan men är bara avslagen.

Men förutom tekniken så finns det också en skillnad i kultur på Mac jämfört med andra plattformar.
Det är mycket samma utvecklare och programhus som på iOS som redan är stängd, och det finns en tradition av att "Apple vet bäst" som gör att jag tror att Mac-användare lättare skulle finna sig i en stängd plattform.

Jag märker inte ord. Förklara vilken funktion i kärnan som bara behöver slås på.

Mac har aldrig varit en "walled garden" och IOS har funnits sedan 2007, varför skulle Apple försöka låsa ner Mac OS när de dessutom gått mot ett öppnare IOS? Numera är det t.om. enkelt att sideloada appar.

Permalänk
Medlem
Skrivet av Findecanor:

Märka ord! Det är skillnad mellan olika OS. Det skulle det vara en ganska liten förändring att stänga av att man kan installera från varsomhelst: funktionen finns redan men är bara avslagen.

Men förutom tekniken så finns det också en skillnad i kultur på Mac jämfört med andra plattformar.
Det är mycket samma utvecklare och programhus som på iOS som redan är stängd, och det finns en tradition av att "Apple vet bäst" som gör att jag tror att Mac-användare lättare skulle finna sig i en stängd plattform.

lol, liten förändring? Så nu menar att marknaden kommer nöja sig med att det kommer iOS installerat på din Macbook? Kommer bli svårt då man skulle utesluta en större del av de som faktiskt utvecklar applikationer till iOS. Hur ska någon kunna utveckla applikationer till iOS på iOS? Du behöver Xcode, dev, test miljö, en del personer vill använda sig av en IDE, etc. Sedan samma sak gäller utveckling till watchOS och tvOS. OSX kommer finnas kvar ett bra tag till för att kunna stötta de andra plattformarna.

Visa signatur

All your base are belong to us

Permalänk
Medlem
Skrivet av bastardjim:

lol, liten förändring? Så nu menar att marknaden kommer nöja sig med att det kommer iOS installerat på din Macbook? Kommer bli svårt då man skulle utesluta en större del av de som faktiskt utvecklar applikationer till iOS. Hur ska någon kunna utveckla applikationer till iOS på iOS? Du behöver Xcode, dev, test miljö, en del personer vill använda sig av en IDE, etc. Sedan samma sak gäller utveckling till watchOS och tvOS. OSX kommer finnas kvar ett bra tag till för att kunna stötta de andra plattformarna.

Xcode fungerar redan felfritt på ipad

Permalänk
Medlem
Skrivet av DasIch:

Förklara vilken funktion i kärnan som bara behöver slås på.

Det är en fråga om policy i den del av kärnan som laddar och kör program: om ett program ska behöva vara signerat av Apple's egen kodserver-farm eller inte för att kunna få köras. På iOS måste alla program vara signerade av Apple.

Skrivet av bastardjim:

Hur ska någon kunna utveckla applikationer till iOS på iOS?

Det var inte vad jag skrev...

Visa signatur

För övrigt anser jag att tobak ska förbjudas.

Permalänk
Medlem

Låter ärligt talat spännande om Apple börjar lansera datorer med ARM-processor. Vad jag minns så arbetade dom väl även på någon slag konvertering av appar för iPad till MacOS, via Mac Catalyst eller vad det kallades för. Så man ser ju en tydlig tendens hur det här kommer sluta. Ganska vågat att ta steget dock, när dom väl gör det.

Permalänk
Medlem
Skrivet av Findecanor:

Det är en fråga om policy i den del av kärnan som laddar och kör program: om ett program ska behöva vara signerat av Apple's egen kodserver-farm eller inte för att kunna få köras. På iOS måste alla program vara signerade av Apple.

Det var inte vad jag skrev...

Även om det inte var det du skrev så fungerar det redan. Jag ser ingen större skillnad än att utveckla för linux på linux eller andra liknande. Xcode går ju redan fint på arm på ipad, vilket tekniskt sett kallas ipad os nu för tiden om man ska vara petig

Permalänk
Medlem
Skrivet av medbor:

Även om det inte var det du skrev så fungerar det redan. Jag ser ingen större skillnad än att utveckla för linux på linux eller andra liknande. Xcode går ju redan fint på arm på ipad, vilket tekniskt sett kallas ipad os nu för tiden om man ska vara petig

Nice, var laddar jag ner Xcode till iPad OS?

Visa signatur

All your base are belong to us

Permalänk
Medlem
Skrivet av bastardjim:

Nice, var laddar jag ner Xcode till iPad OS?

Appstore hade jag för mig, men kanske var något beta-program?

Permalänk
Medlem

Det pratas om att det ska komma i v14 men jag tror inte Xcode finns nu.