morphos

MorphOS 3.12 Beta på AMD64-arkitektur

, indsendt af brostenen

Med adgang til x86 platformen åbner MorphOS muligheden op for at blive langt bredere implementeret, end på tidligere platforme – PowerPC og MC68k.

Man skulle ellers ikke tro det, men den er god nok, MorphOS, oprindeligt fra 2000, kan nu blive det primære operativ-system på din spritnye Ryzen 9 3950x, den er nemlig på vej til x86 platformen. Udgaven af MorphOS fra kilden er næsten to måneder gammel, og udvikleren melder selv ud på twitter, at det godt kan “tage lidt tid” før vi kan få glæde af det nye operativ-system til AMD64.

Tidligere har brugere af MorphOS været begrænset til få hardware modeller, f.eks. G4 Mac Mini’en, eMac’en, Power Mac G5 eller Amiga med PPC udvidelseskort. Men det er altså slut nu. Kernen på den nye MorphOS 3.12 beta kører udover på AMD64, også på PPC32 og PPC64 – man kan altså beholde sin gamle computer, hvis man bare vil opgradere. MorphOS AMD64 udgaven vil derudover indeholde PPC og MC68k emulerering.





Gå til bund
Gravatar

#1 larsp 4. dec. 2019 10:08

Det kan vel også køre på intel chips, der jo understøtter AMD64, eller?
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#2 Molgaard 4. dec. 2019 16:05

larsp (1) skrev:
Det kan vel også køre på intel chips, der jo understøtter AMD64, eller?


Det ville jeg regne med.

Intels 64-bit CPU-løsning hed "Itanium" ... og de vand ikke just nogen populærkonkurrence.

Så nu bruger Intel også AMD64 i alle deres x86 processore.
Gravatar

#3 demolition 4. dec. 2019 17:31

larsp (1) skrev:
Det kan vel også køre på intel chips, der jo understøtter AMD64, eller?

Ja, AMD64 er det som Microsoft kalder x64, så hvis den kan køre Windows 10 x64 så kan den også køre dette OS (med forbehold for at driverudvalget nok bliver ret begrænset).
Gravatar

#4 arne_v 4. dec. 2019 19:12

#AMD64

Kært barn har mange navne.

Jeg vil mene at det mest brugte navn er x86-64.

AMD bruger AMD64.

Intel bruger eller har brugt IA-32e, EM64T og Intel 64.

MS bruger x64.

Men x86-64 er rimeligt vendor neutralt og meget udbredt.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#5 arne_v 4. dec. 2019 19:21

#Itanium

Itanium (IA-64) var vel det mest teknisk lovende design.

x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.

VLIW ideen er genial.

Jeg vil ikke mene at x86-64 har udkonkurreret Itanium, Power, SPARC og Alpha fordi den har et bedre design.

x86-64 har vundet fordi den kunne køre x86 applikationer og dermed blev solgt i hundredevis af millioner af eksemplarer og dermed tjente så mange penge at der kunne investeres mere i design udvikling og fabriks udvikling.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#6 brostenen 5. dec. 2019 01:07

Jeg ser frem til at det kommer på markedet. :-P
Min blog: http://to9xct.blogspot.com

001100 010010 011110 100001 101101 110011

Glad og tilfreds Linux desktop bruger.
Gravatar

#7 larsp 5. dec. 2019 09:05

arne_v (5) skrev:
Itanium (IA-64) var vel det mest teknisk lovende design.

x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.

VLIW ideen er genial.

Det er mit indtryk at VLIW ikke er så genialt igen, for det lægger hele optimiseringsopgaven over på compileren hvor det har vist sig svært at lave kode der udnytter resourcerne optimalt. Dertil kan compileren kun lave ét bud på den optimale organisering af instruktionerne. Alt der sker i runtime kan jo ikke tages med i overvejelserne.

Fylder IA-64 kode ikke også ekstremt meget? Det straffer også performance.

Nu hvor transistorer og logik er blevet så billig, er det nok ikke så dumt at smide så meget som mulig af optimiseringsopgaven ned i CPUen, hvor der kan arbejdes med et midlertidigt oversat instruksionsset, og det er jo også det der har vist sig den vindende formel inden for x64 og ARM.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#8 CBM 5. dec. 2019 11:43

Jeg er glad for at Bigfoot og Co endelig valgte at se nærmere på AMD64

Det var der ellers ikke stemning for i lange tider :)

Hvor dejlig 68k og PPC end er så er det døde platforme men rart at de stadig kan køres via indbyggede emulatorer


https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#9 kblood 5. dec. 2019 18:54

Det lyder interessant :) Måske jeg lige skal have prøvet det igen
Gravatar

#10 kblood 5. dec. 2019 18:57

#8 PPC Amigaer har altid virker underligt for mig... de skulle netop stadig bruge emulator for at køre 68k software. Så hvorfor ikke bare skifte til x86 / x64? Tog dem godt nok lang tid... så håber jeg bare det også sker med AmigaOS4
Gravatar

#11 arne_v 6. dec. 2019 00:11

larsp (7) skrev:
arne_v (5) skrev:
Itanium (IA-64) var vel det mest teknisk lovende design.

x86-64 er stadig en 16 bit arkitektur udvidet til 32 bit udvidet til 64 bit.
VLIW ideen er genial.

Det er mit indtryk at VLIW ikke er så genialt igen, for det lægger hele optimiseringsopgaven over på compileren hvor det har vist sig svært at lave kode der udnytter resourcerne optimalt.


Den forklaring er ret gængs.

Men kan det virkeligt passe at en compiler med næsten uendelig tid til at optimere, adgang til hele koden og mulighed for at løbe gennem koden mange gange er dårligere til at optimere end en CPU som kender nogle få udførte instruktioner og de få næste instruktioner og hvor hvert et nanosekund tæller?

Det synes jeg ikke lyder logisk.

Jeg mener også at benchmarks viste at ved samme antal ekerner of samme frekvens var Itanium langt hurtigere end x86-64. Men Itanium sakkede bagud i antal kerner og frekvens.

larsp (7) skrev:

Dertil kan compileren kun lave ét bud på den optimale organisering af instruktionerne. Alt der sker i runtime kan jo ikke tages med i overvejelserne.


Ifølge den logik bør fortolkning eller ihvertfald JIT kompilering være hurtigere end AOT kompilering.

Selvom JIT kompilering er ret god idag, så er det vel de færreste som ser det som hurtigere end AOT kompilering.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 arne_v 6. dec. 2019 00:33

arne_v (11) skrev:

Men Itanium sakkede bagud i antal kerner og frekvens.


Itanium:

2001: 1 core, 0.8 GHz
2006: 2 cores, 1.6 GHz
2010: 4 cores, 1.7 GHz
2012: 8 cores, 2.5 GHz

Xeon:

2001 (Foster): 1 core, 2.0 GHz
2005 (Paxville): 2 cores, 2.8 GHz
2006 (Clovertown): 4 cores, 2.7 GHz
2008 (Dunnington): 6 cores, 2.7 GHz
2010 (Beckton): 8 cores, 2.7 GHz
2011 (Westmere): 10 cores, 2.7 GHz
2012 (Ivy Bridge): 12 cores, 3.7 GHz
2014 (Haswell) : 18 cores, 3.7 GHz
2017 (Skylake) : 28 cores, 3.9 GHz


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#13 arne_v 6. dec. 2019 01:01

larsp (7) skrev:

Fylder IA-64 kode ikke også ekstremt meget?


Fylder mere.

32 bit CISC typisk:

instruktion: variabel længde
adresse: 4 bytes
integer data: 4 bytes
floating point data: 8 bytes

64 bit CISC typisk:

instruktion: variabel længde
adresse: 8 bytes
integer data: 4 bytes
floating point data: 8 bytes

64 bit RISC typisk:

instruktion: 4 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes

64 bit VLIW typisk:

instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes

Tilfældigt eksempel.

unzip.exe version 5.52:

VAX (32 bit CISC) - 112 KB
Alpha (64 bit RISC) - 160 KB
Itanium (64 bit VLIW) - 400 KB

Det er en pæn stor forskel.

Måske derfor at Itanium kom med pænt store cache.

De sidste modeller (2012 og 2017) kom med:

512 KB L2 I cache per core
256 KB L2 D cache per core
32 MB L3 cache per socket

Xeon Ivy Bridge fra 2012 kom med 256 KB L2 per core og 8 MB L3 per socket.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#14 larsp 6. dec. 2019 07:30

arne_v (13) skrev:
64 bit VLIW typisk:

instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes

16 bytes bare for instruktion(er) Det er jo helt vildt. Jeg tror at det ofte slet ikke kan lade sig gøre at fylde kød på de kæmpe instruktioner, selv med en overnaturlig god compiler. Der er ingen tvivl om at konceptet vil være godt til store matrixberegninger og lignende, men f.eks. små dumme loops med små integers, som jo er ret normalt i kode, må blive straffet.

Det viser sig jo også ved at unzip.exe bliver så bloated. Al den plads der ikke bruges i binarien er vel ækvivalent med units i processoren der ikke laver noget, da processoren ikke kan lave dynamisk reschedulering af operationer osv til at fylde de tomme units ud.

Itanium arkitekturen synes mere egnet til GPU-agtig processering end til general purpose kode.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#15 Retro 6. dec. 2019 09:43

Ohh yes Amiga clone goes x64
Gravatar

#16 brostenen 6. dec. 2019 12:18

kblood (10) skrev:
#8 PPC Amigaer har altid virker underligt for mig... de skulle netop stadig bruge emulator for at køre 68k software. Så hvorfor ikke bare skifte til x86 / x64? Tog dem godt nok lang tid... så håber jeg bare det også sker med AmigaOS4


Jeg tror bare det handler om to ting. På det tidspunkt at man skiftede til PPC, var der alligevel så meget software, som kørte på PPC i forvejen. Og hardware i form af acceleratorer. Til sidst er der jo det fakta, at Amiga verdenen er utrolig konservativ i mange henseender.

Tænk på hvor mange der stadig er imod ARM løsnings snakken.

Jeg mener at både ARM og x86 (64bit) er vejen frem. ARM til små opgaver så som simple spil og tekst behandling og såen. Hvorimod x86 løsning og geforce eller radeon til fotografen og animatoren (3D modellering og video redigering)
Min blog: http://to9xct.blogspot.com

001100 010010 011110 100001 101101 110011

Glad og tilfreds Linux desktop bruger.
Gravatar

#17 CBM 6. dec. 2019 12:35

Retro (15) skrev:
Ohh yes Amiga clone goes x64

Aros og aeros har længe kørt på x64

Ligesom amigaxl, amithlon og amiga forever

Mens morphos og amigaos kører ppc

Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)
https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#18 brostenen 6. dec. 2019 14:57

CBM (17) skrev:

Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)


Bestemt.... Omend de stadig kun har driver understøttelse af få typer grafikkort så som Radeon, så er det muskler der mangles. Jeg ville også syntes det ville være rigtig godt, hvis de også portede til ARM. Jeg snakker ikke om at de skal skifte hele hardware platformen ud, men kun skifte til et par specifikke CPU og Chipset platforme.

Det er muskler der mangles, ikke så meget grafik accelration som sådan.
Min blog: http://to9xct.blogspot.com

001100 010010 011110 100001 101101 110011

Glad og tilfreds Linux desktop bruger.
Gravatar

#19 CBM 6. dec. 2019 15:02

brostenen (18) skrev:
CBM (17) skrev:

Men det er dejligt at morphos endelig også kører x64. Jeg har længe argumenteret overfor udviklerne af morphos at de skulle understøtte x64 :)


Bestemt.... Omend de stadig kun har driver understøttelse af få typer grafikkort så som Radeon, så er det muskler der mangles. Jeg ville også syntes det ville være rigtig godt, hvis de også portede til ARM. Jeg snakker ikke om at de skal skifte hele hardware platformen ud, men kun skifte til et par specifikke CPU og Chipset platforme.

Det er muskler der mangles, ikke så meget grafik accelration som sådan.

Jep men måske kan de blive inspireret af aeros og Linux driver wrapping
https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#20 arne_v 6. dec. 2019 15:10

larsp (14) skrev:

arne_v (13) skrev:
64 bit VLIW typisk:

instruktion: 16 bytes
adresse: 8 bytes
integer data: 4 eller 8 bytes
floating point data: 8 bytes

16 bytes bare for instruktion(er) Det er jo helt vildt.


Der er jo nok en grund til at det heder VLIW (Very Long Instruction Word) og ikke RSIW (Rather Short Instruction Word).

:-)

De 128 bits består af 3 instruktioner som hver fylder 41 bit og 5 bit med indholdsbeskrivelse.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#21 arne_v 6. dec. 2019 15:58

larsp (14) skrev:

Jeg tror at det ofte slet ikke kan lade sig gøre at fylde kød på de kæmpe instruktioner, selv med en overnaturlig god compiler. Der er ingen tvivl om at konceptet vil være godt til store matrixberegninger og lignende, men f.eks. små dumme loops med små integers, som jo er ret normalt i kode, må blive straffet.

...

Itanium arkitekturen synes mere egnet til GPU-agtig processering end til general purpose kode.


Itanium er helt klart designet til parallel eksekvering.

Men den er meget forskellig fra GPU og vector/matrix beregninger.

De er SIMD orienteret.

Itanium er MIMD orienteret.

Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).

Så den kan faktisk udføre meget forskellige ting parallelt.

Hvis der ikke er data dependencies.

Men det er nemmere at undgå data dependencies i Itanium end i x86 / x86-64.

128 styk 64 bit integer registre + 128 styk 82 bit FP registre giver mulighed for at have en masse forskellige temporære værdier.

Rent teknisk er de 128 fordelt på 32 som bruges globalt og 96 som bruges til register windowing for argumenter. D.v.s. at man har et antal registre med de argumenter man er kaldt med, 32 registre til almindelig brug og et antal registre til argumenter man kalder med. Stadig meget pænt.

Jeg kan se noget ide i det.

Men hvis det er den halve frekvens og det halve antal kerner og den firdobbelte pris af x86-64, så falmer ideen meget hurtigt.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#22 larsp 6. dec. 2019 16:09

morphOS

Hvad kan morphos køre? A500/A1200 spil? Bliver der lavet ny software til det? Networking support? Er der en halv-fornuftig browser?
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#23 arne_v 6. dec. 2019 16:16

(rettet - se nedenfor)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#24 arne_v 6. dec. 2019 16:19

#21

Der er selvfølgelig også visse problemer med det niveau af parallelisme og antal registre.

Memory konsistens er noget mere tricky end med x86-64.

Microsoft fik et lille problem da de skulle tilføje Itanium support i .NET i 2.0.

Visse konstruktioner som altid ville virke på x86-64 ville ikke altid virke på IA-64.

Så de var nødt til at definere en .NET memory model, som udviklerne kunne programmere ud fra. Og det var jo i sagens natur nødt til at være en forsigtig model som kunne implementeres på alle platforme.

https://docs.microsoft.com/en-us/archive/msdn-maga...

har en lang forklaring.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#25 larsp 6. dec. 2019 16:35

arne_v (21) skrev:
Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).

Så den kan faktisk udføre meget forskellige ting parallelt.

Hvis der ikke er data dependencies.

Det lyder som om branching og looping kan kaste grus i maskineriet. Hvis det ene eksekverings spor har brug for en anden execution path end de andre kan de jo ikke køre sideløbende.

Men IA-64 er bestemt en interessant case at lære om. Det kan vel minde lidt om PS3 og dens cell processor. Masser af teoretisk power, men ekstremt svært at udnytte det fulde potentiale i praksis. Hvorimod x86/arm/... kan ses som general purpose / brute force monsteret der bare æder sig igennem hvad som helst med glubende appetit.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#26 larsp 6. dec. 2019 16:40

#24 Fra linket.. har ikke læst det hele, men denne springer i øjnene:
class Test
{
private bool _flag = true;
public void Run()
{
// Set _flag to false on another thread
new Thread(() => { _flag = false; }).Start();
// Poll the _flag field until it is set to false
while (_flag) ;
// The loop might never terminate!
}
}

In this case, the .NET 4.5 JIT compiler might rewrite the loop like this:

if (_flag) { while (true); }

C programmørens kommentar, _flag skal deklareres volatile!!! ellers skal der gives dummekage ;) Nå, men, gad vide om der overhovedet findes volatile i C#
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#27 arne_v 6. dec. 2019 16:46

#26

De næste linier siger:


In the single-threaded case, this transformation is entirely legal and, in general, hoisting a read out of a loop is an excellent optimization. However, if the _flag is set to false on another thread, the optimization can cause a hang.

Note that if the _flag field were volatile, the JIT compiler would not hoist the read out of the loop. (See the “Polling Loop” section in the December article for a more detailed explanation of this pattern.)


så ja - C# har volatile.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#28 arne_v 6. dec. 2019 17:37

#27

Det er værd at bemærke at så vidt jeg ved (med mit begrænsede kendskab til memory modeller) så:
* har C volatile samme semantik som Java pre-1.5 volatile d.v.s. at de sikrer konsistent adgang til variablen der er volatile
* har C# volatile samme semantik som Java 1.5 og nyere volatile d.v.s som ovenstående plus etablerer en happens-before order
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#29 arne_v 6. dec. 2019 17:56

larsp (25) skrev:
arne_v (21) skrev:
Instruktioner kommer ind i bundter af 3, men der kan godt være flere bundter i gang samtidigt. Og der er flere eksekverings enheder af hver slags (hvis man kan stole på wikipedid artiklen: 12 integer arithmentik enheder, 2 double precision FP arithmentik enheder, 2 single precision FP arithmetik enheder etc.).

Så den kan faktisk udføre meget forskellige ting parallelt.

Hvis der ikke er data dependencies.

Det lyder som om branching og looping kan kaste grus i maskineriet. Hvis det ene eksekverings spor har brug for en anden execution path end de andre kan de jo ikke køre sideløbende.


Det er vel næsten perfekt til et for loop.

for(i = 0; i < n; i++) {
c[i] = a[i] + b[i];
}

er for hvert gennemløb:
* beregn address a[i]
* beregn address b[i]
* beregn address c[i]
* hent a[i]
* hent b[i]
* gem c[i]
* plus
* forøg i
* sammenlign i og n og hop hvis ikke mindre
* hop op
=
2 load
1 store
4 integer arithmetic
1 FP arithmentic
2 branch

Hvis compileren kan arrangere det rigtigt, så kan del vel parelleliseres til kun 2 clock cycles.

Itanium bruger speculative/predictive execution ligesom x86-64, så et forkert gæt koster for dem begge, omend det nok koster mere for Itanium da der formentligt er mere in fligth som er spildt.

Men for et loop som ovenfor er det n rigtige gæt og 1 forkert gæt.



The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#30 arne_v 6. dec. 2019 17:58

#29

Ovenstående loop disskering forudsætter ingen loop unroll, hvilket ikke er realistisk med idags compilere, men loop unrolling ændrer ikke meget på instruktions mixet - det reducerer kun andelen af branches - så paralelliseringsmuligheden er den samme.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#31 CBM 6. dec. 2019 17:59

Dad joke: ja jeg hader også når klokkerne bliver for varme, hvis man cykler mere end der er behov for

:)
https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login