apple officielt køber intel 5g mobilteknologi modem division bekræftet qualcomm / Newz.dk

Newz

Rygte: Apple måske på vej væk fra intel

- , indsendt af arne_v

Bloomberg rapporterer at Apple kan være på vej væk fra den populære chip-producent

Selvom det har været på tale længe i mange år, melder en analytiker nu at der angiveligt skulle være ARM-baserede Apple bærbare på vej i 2021.

Processorerne de nye bærbare meldes at komme med, kendes fra Apples allerede eksisterende telefoner og tablets. 

Fordelen for Apple, skulle være at få mere kontrol med platformen og selv være ansvarlig for hele leveringskæden af deres enheder.

Apple har benyttet Intels processorer, siden de skiftede fra IBMs PowerPC processorer i 2006.





Gå til bund
Gravatar #1 - brostenen
27. apr. 2020 22:56
Hvis det virker, så virker det. Hvis det bliver noget lort, så bliver det noget lort. Lad os se om de gør det, og så studere resultatet.
Gravatar #2 - graynote
28. apr. 2020 05:43
brostenen (1) skrev:
Hvis det virker, så virker det. Hvis det bliver noget lort, så bliver det noget lort. Lad os se om de gør det, og så studere resultatet.


Også er der alle mellmevejene:

1)
Hvordan lægger det sig i forhold til strømforbrug?

2)
I hvilket omfang, hvis noget, følger der software issues med skiftet til ARM?

Microsoft har haft en række udfordringer med ARM-baserede windowsmaskiner i forhold til især legacy software. Apple er godt nok med noget mindre sårbar her, (Apple har på godt og ondt aldrig prioriteret bagudkompatibilitet højt), men det er alligevel et relevant punkt med potentielt stor betydning. Downtime er en dræber.

3)
Hvordan kommer performance i forskellige scenarier til at være? Det er typisk forskelligt fra cpu til cpu, hvad der excelleres i. Viser de nye chips sig at adskille sig væsentligt fra Intel? Og hvordan passer det med den måde Apples kunders brugsmønstre?

4)
Pris. Prisskalaen for hvorvidt skiftet "virker" eller bliver "noget lort" for Apple har antageligt flere end de to punkter.

5)
Pålidelighed / holdbarhed. Hvis der er noget kunder generelt og virksomheder i særdeleshed hader, så er det fejl og downtime.

6)
Forsyningssikkerhed. Kommer Apple pludseligt til at mangle chips?

I dag kan Apple spille med musklerne og kræve at blive prioriteret over andre kunder, hvis Intel skulle få problemer med at levere chips. Noget der bestemt ikke er uhørt i forbindelse med nye chips med lave yields (eller i forbindelse med coronakriser).

Med sær/egendesignede chips så ER der ikke andre kunder at komme foran - hvis der er leveringsproblemer, så er der leveringsproblemer. Det er ikke sådan bare lige et skalere en chip-produktion op, så selv uden kriser og katastrofer og selv med perfekt produktion, så kan helt almindelige efterspørgsels-overraskelser give leveringsproblemer.

7)
Måske vigtigst: Fremadrettet udvikling; kan et roadmap overholdes - i forhold til performance, i forhold til tid, i forhold til wafer yield, i forhold microcode.

Og også vigtigt; selv hvis roadmaps overholdes, hvordan viser udviklingen så at være i forhold til udviklingen hos AMD og Intel?




Så altså, det er meget mere komplekst end at det enten "virker" eller bliver "noget lort". Det kan også virke på nogle områder og slet ikke på andre.
Gravatar #3 - larsp
28. apr. 2020 06:39
Apples ARM chips performer afsindig godt, og det er chips designet til at sidde i små håndholdte enheder. Når der designes til laptops og desktops kan de igen øge performance betydeligt. Jeg tror bestemt de kan lave konkurrencedygtige chips til x86, så hvorfor ikke give Intel sparket. Kunderne æder jo alt fra det afbidte æble.

At være herre i eget hus er nok en vigtig årsag. Well, 95% af komponenterne vil stadig være produceret af tredjepartsleverandører, men det er komponenter hvor man nemt kan finde alternative producenter, og så får man forsyningssikkerhed og forhandlingsmuligheder. Intel CPUer bliver kun lavet ét sted og så er det svært at manøvrere. Der er selvfølgelig AMD, men de kan jo ikke bare smides i samme sokkel, som man kan med en RAM klods.
Gravatar #4 - kblood
28. apr. 2020 17:47
Jeg tænker det måske var grunden til den opdatering de har lavet der er 64bit only af deres MacOS? Men det betyder vel også at man så ikke kan køre Windows på dem længere? Og den opdatering af MacOS har allerede givet en del problemer med at køre software.

Men bliver lidt spændende at se hvordan det kommer til at gå. Hvis det er strømeffektivt så er jeg da interesseret.
Gravatar #5 - arne_v
28. apr. 2020 18:48
graynote (2) skrev:

1)
Hvordan lægger det sig i forhold til strømforbrug?


Strømforbruger må blive langt mindre.

graynote (2) skrev:

2)
I hvilket omfang, hvis noget, følger der software issues med skiftet til ARM?

Microsoft har haft en række udfordringer med ARM-baserede windowsmaskiner i forhold til især legacy software. Apple er godt nok med noget mindre sårbar her, (Apple har på godt og ondt aldrig prioriteret bagudkompatibilitet højt), men det er alligevel et relevant punkt med potentielt stor betydning. Downtime er en dræber.


macOS/x64-64 kode kører ikke native på macOS/ARM - enten skal de emulere eller så skal der genoversættes.

Gravatar #6 - arne_v
28. apr. 2020 18:52
larsp (3) skrev:

Apples ARM chips performer afsindig godt, og det er chips designet til at sidde i små håndholdte enheder. Når der designes til laptops og desktops kan de igen øge performance betydeligt.


Det er altså:

idag - god performance i telefoner/tablets
fremtid - god performance i laptops/desktops
Gravatar #7 - arne_v
28. apr. 2020 18:54
kblood (4) skrev:

Men det betyder vel også at man så ikke kan køre Windows på dem længere?


Medmindre du tænker på ARM udgaven, så vil det kræve emulering.

kblood (4) skrev:

Men bliver lidt spændende at se hvordan det kommer til at gå. Hvis det er strømeffektivt så er jeg da interesseret.


Det er uden tvivl strømeffektivt.
Gravatar #8 - brostenen
28. apr. 2020 21:25
graynote (2) skrev:
brostenen (1) skrev:
Hvis det virker, så virker det. Hvis det bliver noget lort, så bliver det noget lort. Lad os se om de gør det, og så studere resultatet.


Også er der alle mellmevejene:

1)
Hvordan lægger det sig i forhold til strømforbrug?

2)
I hvilket omfang, hvis noget, følger der software issues med skiftet til ARM?

Microsoft har haft en række udfordringer med ARM-baserede windowsmaskiner i forhold til især legacy software. Apple er godt nok med noget mindre sårbar her, (Apple har på godt og ondt aldrig prioriteret bagudkompatibilitet højt), men det er alligevel et relevant punkt med potentielt stor betydning. Downtime er en dræber.

3)
Hvordan kommer performance i forskellige scenarier til at være? Det er typisk forskelligt fra cpu til cpu, hvad der excelleres i. Viser de nye chips sig at adskille sig væsentligt fra Intel? Og hvordan passer det med den måde Apples kunders brugsmønstre?

4)
Pris. Prisskalaen for hvorvidt skiftet "virker" eller bliver "noget lort" for Apple har antageligt flere end de to punkter.

5)
Pålidelighed / holdbarhed. Hvis der er noget kunder generelt og virksomheder i særdeleshed hader, så er det fejl og downtime.

6)
Forsyningssikkerhed. Kommer Apple pludseligt til at mangle chips?

I dag kan Apple spille med musklerne og kræve at blive prioriteret over andre kunder, hvis Intel skulle få problemer med at levere chips. Noget der bestemt ikke er uhørt i forbindelse med nye chips med lave yields (eller i forbindelse med coronakriser).

Med sær/egendesignede chips så ER der ikke andre kunder at komme foran - hvis der er leveringsproblemer, så er der leveringsproblemer. Det er ikke sådan bare lige et skalere en chip-produktion op, så selv uden kriser og katastrofer og selv med perfekt produktion, så kan helt almindelige efterspørgsels-overraskelser give leveringsproblemer.

7)
Måske vigtigst: Fremadrettet udvikling; kan et roadmap overholdes - i forhold til performance, i forhold til tid, i forhold til wafer yield, i forhold microcode.

Og også vigtigt; selv hvis roadmaps overholdes, hvordan viser udviklingen så at være i forhold til udviklingen hos AMD og Intel?




Så altså, det er meget mere komplekst end at det enten "virker" eller bliver "noget lort". Det kan også virke på nogle områder og slet ikke på andre.


Hvis du er iSheep, er alt det der sort snak. Det skal bare virke og skinde flot, så er fåret glad.
Gravatar #9 - arne_v
29. apr. 2020 00:44
#strøm

Jeg mener at A12 har TDP på 5 watt mens Coffee Lake har TDP på 45 watt.
Gravatar #10 - Molgaard
29. apr. 2020 11:04
... og så er der hele detaljen med at alle programmer skal kompileres til ARM.

Med undtagelse af applikationer som er kompileret til bytecode (Java) eller CLR (dotnet core), så kan du ikke afvikle x86 programmer i et ARM miljø.

Du vil se et markant performance tab i så fald, fordi x86 miljøet skal emuleres, hvilket gør ARM uinteressant.

Og rent arkitektonisk er der også forskel på Intel (CISC) og ARM (RISC), fordi processoren opfører sig ikke ens på binært niveau.

Den samme abstrakte instruktion på en CISC processer kan sagtens tage fire gange eller længere tid at afvikle på på en RISC processer, fordi CISC vil gemme variabler i et separat register i L1, mens RISC processoren skal swappe data med L2 (eller måske ligefrem L3) ved den samme operation.

Eller hvordan vil talberegninger blive håndterer?

Bliver der også et skift imellem LittleIndian og BigIndian?

Summa Summarum:

At omskrive et operativsystem fra x86 til ARM er alt andet end trivielt.
Gravatar #11 - arne_v
29. apr. 2020 11:35
Molgaard (10) skrev:

... og så er der hele detaljen med at alle programmer skal kompileres til ARM.

Med undtagelse af applikationer som er kompileret til bytecode (Java) eller CLR (dotnet core), så kan du ikke afvikle x86 programmer i et ARM miljø.

Du vil se et markant performance tab i så fald, fordi x86 miljøet skal emuleres, hvilket gør ARM uinteressant.


Det gør ikke ARM uinteressant (for Mac) men det gør kode oversat til x86-64 (på Mac) uinteresant (på ARM Mac's).

Molgaard (10) skrev:

Og rent arkitektonisk er der også forskel på Intel (CISC) og ARM (RISC), fordi processoren opfører sig ikke ens på binært niveau.

Den samme abstrakte instruktion på en CISC processer kan sagtens tage fire gange eller længere tid at afvikle på på en RISC processer, fordi CISC vil gemme variabler i et separat register i L1, mens RISC processoren skal swappe data med L2 (eller måske ligefrem L3) ved den samme operation.


????

Registre har ikke noget med L1 at gøre.

RISC CPU kan bruge L1 fuldstændigt ligesom CISC CPU kan.

Molgaard (10) skrev:

Bliver der også et skift imellem LittleIndian og BigIndian?


Formenligt ikke. ARM er bi-endiaa, men default er little endian.

Molgaard (10) skrev:

Summa Summarum:

At omskrive et operativsystem fra x86 til ARM er alt andet end trivielt.


Da Apple er gået:

M68K -> PPC -> x86-64

allerede så ved de nok hvad x86-64 -> ARM involverer.
Gravatar #12 - larsp
29. apr. 2020 12:05
#10 Angående CISC vs RISC er det blevet en mere og mere akademisk diskussion, for internt i en moderne CISC som x86 bliver instruktionerne alligevel oversat til et midlertidigt instruktionsset der passer optimalt til processorens resourcer.

Jeg tænker at det mest avancerede ARM'er også gør noget i den stil, og hvis ikke kommer de nok til det en dag. Så instruktionssættet, hvis det ikke spilder en masse båndbredde, er ikke så kritisk igen.
Gravatar #13 - brostenen
29. apr. 2020 13:01
Der skal lige tilføjes, at du Apple skiftede før i tiden, brugte de rosetta mellemlagret, for at høre software compatibelt. Det var genialt, da det gav udviklere tid til at omskrive eller de kunne vælge at udgive ny type software. Så gav det brugeren mulighed for at køre gammelt software også.
Gravatar #14 - arne_v
29. apr. 2020 13:20
#13

Og deres fat/universal binary koncept, hvor man kunne compile til en enkelt binary som indeholdt kode for begge CPU typer.
Gravatar #15 - jespersen.thomas
29. apr. 2020 14:45
Da Steve Jobs præsenterede overgangen til Intel Processorer afslørede han at Apple havde et "hemmeligt" lab hvor OSX allerede havde kørt på Intel i flere år.

Det skulle ikke undre mig om de allerede har OSX kørende på ARM internt.

Gravatar #16 - arne_v
29. apr. 2020 15:02
larsp (12) skrev:

#10 Angående CISC vs RISC er det blevet en mere og mere akademisk diskussion, for internt i en moderne CISC som x86 bliver instruktionerne alligevel oversat til et midlertidigt instruktionsset der passer optimalt til processorens resourcer.


Ah. Den kendte historie om at x86-64 oversætter fra CISC til RISC.

Så vidt jeg ved er det en vandrehistorie. En vandrehistorie baseret på en misforståelse.

x86-64 ligesom alle andre CISC ISA gennem de sidste 40-50 år bruger mikrokode. Mikrokode er mere simple instruktioner til hardwaren. Det muliggør komplekse instruktioner uden at bloate hardwaren. Og det muliggør store ændringer i hardwaren uden at ændre ISA d.v.s. opretholde binær kompabilitet.

Mikrokode instruktioner ligner mere RISC makrokode instruktioner end CISC makrokode instruktioner. Men at kalde det en oversættelse til RISC er stadig noget søgt.


Gravatar #17 - arne_v
29. apr. 2020 15:07
larsp (12) skrev:

Jeg tænker at det mest avancerede ARM'er også gør noget i den stil, og hvis ikke kommer de nok til det en dag. Så instruktionssættet, hvis det ikke spilder en masse båndbredde, er ikke så kritisk igen.


ARM har mikro-operationer idag.

Men så vidt jeg kan læse mig til er makro til mikro hardcoded i silicium på ARM mens det for x86-64 er firmware (hvilket betyder at det kan opdateres uden at skifte CPU).
Gravatar #18 - arne_v
29. apr. 2020 15:16
#16

Noget andet er at RISC og CISC er ret vage begreber.

Jeg tror at den eneste mulige hårde definition er:
RISC - alle instruktioner har samme længde
CISC - instruktioner har forskellig længde
og de afledte konsekvernser for addressering.

For der er RISC ISA'er med ret avancerede instruktioner og der er CISC ISA'er med kun basale instruktioner.

Gravatar #19 - CBM
29. apr. 2020 16:04
* danser lige 'I told you so' dansen * for all the Apple lovers out there

Gravatar #20 - CBM
29. apr. 2020 16:17
Jeg er ret sikker på at de laver samme trick som da de skiftede fra 68k til ppc og fra ppc til intel


Så må vi heller ikke glemme at Apple dybest set er skide ligeglade med laptops og stationære

De ønsker at ipads skal afløse begge typer af computere men de ønsker ikke at give deres tablets mere funktionalitet end højst nødvendigt


Jeg er stadig flad af grin over deres 2000 dollar monitor metal fod
Gravatar #21 - CBM
29. apr. 2020 17:19
Jeg holder fast i mine betragtninger fra 2017,18,19 og i år angående ARM baserede Apple enheder.

*emperor palpatines voice* my hatred for Apple burns brighter than ever before... mwuhahhaha
Gravatar #22 - dub
29. apr. 2020 19:09
CBM (20) skrev:

Jeg er stadig flad af grin over deres 2000 dollar monitor metal fod

Jeg er stadig flad af grin over hvor dårlig du er til at forstå Apple.
Gravatar #23 - CBM
30. apr. 2020 03:34
dub (22) skrev:
CBM (20) skrev:

Jeg er stadig flad af grin over deres 2000 dollar monitor metal fod

Jeg er stadig flad af grin over hvor dårlig du er til at forstå Apple.

Jeg var ikke klar over at firmaer havde behov for at blive "forstået" :-)

Men på den anden side kan jeg godt forstå at de sætter deres priser som de gør sålænge de kan få folk til at betale.
Gravatar #24 - larsp
30. apr. 2020 06:43
arne_v (16) skrev:
larsp (12) skrev:

#10 Angående CISC vs RISC er det blevet en mere og mere akademisk diskussion, for internt i en moderne CISC som x86 bliver instruktionerne alligevel oversat til et midlertidigt instruktionsset der passer optimalt til processorens resourcer.


Ah. Den kendte historie om at x86-64 oversætter fra CISC til RISC.

Så vidt jeg ved er det en vandrehistorie. En vandrehistorie baseret på en misforståelse.

x86-64 ligesom alle andre CISC ISA gennem de sidste 40-50 år bruger mikrokode. Mikrokode er mere simple instruktioner til hardwaren. Det muliggør komplekse instruktioner uden at bloate hardwaren. Og det muliggør store ændringer i hardwaren uden at ændre ISA d.v.s. opretholde binær kompabilitet.

Mikrokode instruktioner ligner mere RISC makrokode instruktioner end CISC makrokode instruktioner. Men at kalde det en oversættelse til RISC er stadig noget søgt.

Vandrehistorie, misforståelse? Jeg kan ikke se at du har modsagt noget af det jeg skrev overhovedet :) Et midlertidigt instruktionsset optimeret til processorens resourcer er jo præcis definitionen af mikrokode, og det var det jeg mente.

Men du har nok ret i at mikrokode ikke er så nyt igen, og at selv RISC-agtige processorer har benyttet sig af det i et stykke tid. Men det er stadig et kæmpe segment af microcontrollere og low-power arkitekturer der kører instruktionssættet uden oversættelse (her tænker jeg på 8 og 16 bit arkitekturer). Gad vide om allerede Arm Cortex-M familien har et mikrokode lag. Det har den nok, for den understøtter forskellige instruktionssæt.
Gravatar #25 - larsp
30. apr. 2020 06:51
#instruktionssæt

Som sagt, det er en akademisk diskussion. Det hele ender jo alligevel med processorer der bare kører javascript direkte, når man ser på den retning tingene tager ;) - slet skjult rant over node.js og js-relaterede sprogs sejrsgang gennem hele branchen...
Gravatar #26 - Molgaard
30. apr. 2020 10:36
larsp (25) skrev:
Det hele ender jo alligevel med processorer der bare kører javascript direkte, når man ser på den retning tingene tager ;)


Så skal der laves noget om på CPUen.

Tag bare noget så simpel som en FOR-løkke.

Her har du variabler og betingelser, som skal være opfyldt før de enkelte statements i løkken kan blive afviklet.

Mig bekendt skal du stadigvæk oversætte hver FOR-løkke til en håndfuld microkode statements.

For ikke at tale om algoritmer for hvordan man laver matematiske operationer på kommatal.

... og derudover mindes jeg noget med "sliding windows" dengang jeg i tidernes more var med til at lave en kompiler.

Hvor meget kan du presse ind af instruktioner, før du skal swappe data med hukommelsen?

Edit:

Da jeg skrev kompileren, kunne man udføre 8 instruktioner i et register vindue, før der skulle swappes data med L1 hukommelsen.

Og swap af data var altid tidsmæssigt dyrt, det var blot et spørgsmål om hvor dyrt alt efter om data skulle hentes fra L1, L2, L3, RAM eller harddisk.

Det er derfor det kan betale sig at optimere mikrokode.

Fordi hvis man reducere mikrokoden med blot en enkelt linje, så fik man en performance forøgelse på 12,5% eller højere per optimeret assambler instruktion.

På moderne CPUer ser det ud til tallet for register vindue er på den anden side af 100, så her bliver gevinsten ved optimering tilsvarende midre.

Dermed ikke sagt at det kan ikke betale sig at optimere på "slamkode", fordi det kan det. Det er blot at de lavt hængende frugter er plukket.
Gravatar #27 - arne_v
30. apr. 2020 14:24
larsp (24) skrev:
arne_v (16) skrev:
larsp (12) skrev:

#10 Angående CISC vs RISC er det blevet en mere og mere akademisk diskussion, for internt i en moderne CISC som x86 bliver instruktionerne alligevel oversat til et midlertidigt instruktionsset der passer optimalt til processorens resourcer.


Ah. Den kendte historie om at x86-64 oversætter fra CISC til RISC.

Så vidt jeg ved er det en vandrehistorie. En vandrehistorie baseret på en misforståelse.

x86-64 ligesom alle andre CISC ISA gennem de sidste 40-50 år bruger mikrokode. Mikrokode er mere simple instruktioner til hardwaren. Det muliggør komplekse instruktioner uden at bloate hardwaren. Og det muliggør store ændringer i hardwaren uden at ændre ISA d.v.s. opretholde binær kompabilitet.

Mikrokode instruktioner ligner mere RISC makrokode instruktioner end CISC makrokode instruktioner. Men at kalde det en oversættelse til RISC er stadig noget søgt.


Vandrehistorie, misforståelse? Jeg kan ikke se at du har modsagt noget af det jeg skrev overhovedet :) Et midlertidigt instruktionsset optimeret til processorens resourcer er jo præcis definitionen af mikrokode, og det var det jeg mente.

Men du har nok ret i at mikrokode ikke er så nyt igen, og at selv RISC-agtige processorer har benyttet sig af det i et stykke tid.


Praktisk taget alle CPU både CISC og RISC bruger mikro-kode en eller anden form.

For CISC's vedkommende fra før moderne RISC (SPARC, Power, PA, MIPS) blev opfundet.

Og det ændrer ikke så meget på RISC vs CISC karakteristika. RISC gør det nemmere at starte processingen af nye instuktioner, fordi de har fast længde. CISC vil ihvertfald i nogle tilfælde kræve færre instruktioner hvilket betyder mindre instruktions data skal læses.

Lad os tage et hypotetisk tilfælde:

RISC: 3 instruktioner, alle 4 byte
CISC: 2 instruktioner, en 5 bytes og en 2 byte

at de evt. ender op som henholdsvis 8 + 2 + 6 og 12 + 4 mikro-ops gør dem ikke ens - ikke engang hvis mikro-ops er ens.


Gravatar #28 - arne_v
30. apr. 2020 14:30
larsp (25) skrev:

#instruktionssæt

Som sagt, det er en akademisk diskussion. Det hele ender jo alligevel med processorer der bare kører javascript direkte, når man ser på den retning tingene tager ;) - slet skjult rant over node.js og js-relaterede sprogs sejrsgang gennem hele branchen...


Jeg tror ikke meget på et JS ISA.

Node.js er ret populært men mange steder er det er ret tyndt lag.

Ebay eksempel:

https://www.ebayinc.com/stories/news/node-js-an-op...

"Our Node.js layer acts as a thin web client. It currently talks to a pool of backend services on our platform, called Experience Services,"

"Experience Services power all user-facing experiences, which includes iOS, Android and the web. These services output render-ready data that can be directly consumed by the Node.js layer and rendered as HTML."



Gravatar #29 - arne_v
30. apr. 2020 14:38
#28

Aka implementering af API Gateway Pattern.

:-)
Gravatar #30 - arne_v
30. apr. 2020 15:28
#28

Der er selvfølge også dem der bruger Node som ægte backend: MEAN, MERN etc..

Men for mange af de store er det kun en tynd frontend.
Gravatar #31 - larsp
30. apr. 2020 15:53
En processor der kører js er absurd og var selvfølgelig en joke :) Men man ved jo aldrig, som sagt, når man tager i betragtning hvor meget js breder sig disse dage.
Gravatar #32 - larsp
30. apr. 2020 16:05
#27 Alle moderne? processorer kører med mikrokode. Ja, du har nok ret. Og det får mig til at føle mig lidt gammel, jeg skrev i mit første job assemblerkode til Motorola 68HC12 (det er et af det lækreste instruktionssæt btw.), jeg har lavet enormt meget til AVR 8-bit, inklusiv assembler, AVR XMega, og på hobby plan nørklet med 6810 til C64. Dertil Intel 8051, craptastic PIC 8-bit og Texas MSP430. Uden at vide det, vil jeg gætte på at ingen disse processorer kører med mikrokode oversættelse. Men jeg kan tage fejl.
Gravatar #33 - arne_v
30. apr. 2020 17:01
#32

Det går ihvertfald lagt tilbage.

Så vidt jeg kan læse mig til var den første computer med microcode IBM System/360 fra 1964.

https://en.wikipedia.org/wiki/Intel_Microcode

har lidt on x86 bl.a.:


During the mid-1980s NEC and Intel had a long-running court case under Judge William Austin Ingram, and subsequently Judge William Percival Gray, about microcode copyright. NEC had been acting as a second source for Intel 8086 CPUs with its NEC μPD8086, and held long-term patent and copyright cross-licensing agreements with Intel. In August 1982 Intel sued NEC for copyright infridgement over the microcode implementation. NEC prevailed by demonstrating via cleanroom software engineering that the similiarites in the implementation of microcode on its V20 and V30 processors was the result of the restrictions demanded by the architecture, rather than via copying.


Microcode er også et stort emne i den her meget kendte bog:
https://en.wikipedia.org/wiki/The_Soul_of_a_New_Ma...


++++

Hvis de CPU'er du nævner har meget simple ISA så kan de sagtens være hardwired.
Gravatar #34 - arne_v
30. apr. 2020 17:22
#33

Nogen instruktioner ligger meget op til microcode. Eksempler:
* variabel længde flyt of of sammenligning af bytes
* variabel længde BCD operationer

Nogle specifikke VAX instruktioner:

CASEx værdi, base, antal, jump offset hvis værdi - base er 0, jump offset hvis værdi - base er 1, ...

POLYx værdi, antal led, addresse for tabel med koeeficienter
Gravatar #35 - Remmerboy
3. maj 2020 22:37
De smider bare ios på bærbaren, og så arbejder de videre derfra, ligesom de gjorde ved ipad'en.
Så vil kommende macbooks understøtte touchskærm, og et par år efter, vil isheeps påstå at apple kom først med touchskærm til bærbare
Gravatar #36 - CBM
4. maj 2020 03:20
Remmerboy (35) skrev:
De smider bare ios på bærbaren, og så arbejder de videre derfra, ligesom de gjorde ved ipad'en.
Så vil kommende macbooks understøtte touchskærm, og et par år efter, vil isheeps påstå at apple kom først med touchskærm til bærbare

Lige præcis
Gravatar #37 - larsp
4. maj 2020 04:48
#35 #36 jep, og den almene computerbrugere bliver dummere og dummere. Om 10 år vil IT-kyndige der selv håndterer deres filer og ikke bare har "music i itunes", "dokumenter i office" og "billeder hos google", blive set som nogle skøre gamle nisser.
Gravatar #38 - CBM
4. maj 2020 08:14
#37: men måske kan det betyde at "ægte" computere igen bliver noget for de indviede ligesom i 80erne og 90erne
Gravatar #39 - Claus Jørgensen
4. maj 2020 08:35
#37

Har i stadigvæk filer? Jeg bruger Spotify til musik, og de eneste dokumenter jeg har er mit CV (i O365) og PDF kopier af mine pas.

Gravatar #40 - larsp
4. maj 2020 10:33
#39 Okay, og jeg ejer kun et lændeklæde og en fiskestang..
Gravatar #41 - arne_v
4. maj 2020 15:24
#39

Jeg har lidt filer.

Min arbejds PC siger 331K og min hjemme PC siger 3.1M.
Gravatar #42 - larsp
4. maj 2020 15:55
Fotos og videoer. Unik musik der ikke er mulig at finde mere, backups af tonsvis af gamle projekter. Scans af samtlige lønsedler, hvis nogen skulle undre sig over hvor diverse penge kommer fra. Er jeg den eneste der gemmer på den slags? :)
Gravatar #43 - Claus Jørgensen
4. maj 2020 16:09
#42

Jeg har også lønsedler i PDF, men de ligger på mit OneDrive. Jeg har praktisk talt intet der ikke er auto-backup'd in skyen.

Alle mine billeder ligger også i skyen. Jeg har 2 (3) laptops, 1 stationær, 1 ipad og 2 telefoner. Offline filer er ret træls :p
Gravatar #44 - kblood
4. maj 2020 16:28
Jeg horder når det gælder filer. Ved at løbe tør for plads? Ny SDD eller HDD, og hvis der mangler plads eller kun er en plads tilbage, så fordobbel pladsen på en af de eksisterende diske så jeg kan udskifte den.

Det er også vigtigt at prøve at få hurtigere diske, for når man kommer op på mere end 5tb plads i alt + eksterne diske og sådan, så går det ikke at have for mange HDD... HDD er simpelthen ved at være for langsomt. Men det er stadigt HDD jeg bruger til det meste data. Lige nu har jeg en 3tb HDD og det er næsten halvdelen af min disk plads, men nu er jeg igen ved at komme i plads problemer. Så den skal skiftes ud med en disk der er mindst 6tb. Jeg har også en M.2 SSD som kun er 250gb. Det var nu mest fordi den kom gratis med min computer... så den skal helt klart udskiftes. Virker som spild af plads og strøm at have en disk der er under 1tb i størrelse.

Min bærbar har kun 256gb i alt og nu har jeg en USB stick jeg bruger til forskellige ting. Der findes ret hurtige USB sticks, nogen har 300mb læse og skrive hastighed. Så tænker jeg skal have fat i en 256gb af sådan en, men bærbaren skal også snart udskiftes. Bærbaren kom til at blive formateret ved et uheld og jeg mistede forskellige projekter jeg havde glemt at tage backup af... ret øv. Heldigvis ikke et af mine bedste, men stadigt den slags der får mig til at prøve at have mindst 3 backups af alt.

Så jeg kan slet ikke forstå når folk snakker om ikke at have almindelige filer. Jeg har da en hel del i skyen, men... der er bare noget betryggende ved at have en god bunke filer lokalt så at et Internet nedbrud ikke betyder jeg er er uden spil, music, film, Unity assets, emulatorer, lydbøger, osv osv
Gravatar #45 - larsp
5. maj 2020 05:21
Claus Jørgensen (43) skrev:
#42

Jeg har også lønsedler i PDF, men de ligger på mit OneDrive. Jeg har praktisk talt intet der ikke er auto-backup'd in skyen.

Alle mine billeder ligger også i skyen. Jeg har 2 (3) laptops, 1 stationær, 1 ipad og 2 telefoner. Offline filer er ret træls :p

Livet i skyen er praktisk, ingen diskussion. Men så slæber du jo stadig rundt på *filer*

Jeg tænkte på Apple trenden med ikke at håndtere filer mere, som iOS lægger op til. Alt materiale lever inde i de forskellige Apps. Unge mennesker der er flasket op med iphones har mistet forståelsen og evnen til at håndtere *filer* på grund af dette...
Gravatar #46 - larsp
5. maj 2020 05:30
kblood (44) skrev:
Jeg horder når det gælder filer. Ved at løbe tør for plads? Ny SDD eller HDD

kblood (44) skrev:

Så jeg kan slet ikke forstå når folk snakker om ikke at have almindelige filer. Jeg har da en hel del i skyen, men... der er bare noget betryggende ved at have en god bunke filer lokalt så at et Internet nedbrud ikke betyder jeg er er uden spil, music, film, Unity assets, emulatorer, lydbøger, osv osv

Jeg er helt enig. Det er en god fornemmelse at være selvforsynende og ikke afhængig af en internet forbindelse.

Jeg prøver dog at undgå showet med at lægge ting på diverse løse drev der kan blive væk osv. Det hele skal på serveren, som har to grundlæggende kategorier, hvad der skal backes op (sker automatisk), og hvad der ikke behøver backup. Og så selfhoster jeg iøvrigt Seafile, som er en gør det selv Dropbox. Virker ret godt.
Gravatar #47 - CBM
6. maj 2020 14:38
Det umulige er sket....

Jeg har købt en iMac med en core duo processer og 2 GB ram... tidligt 2006 model

Jeg har nogle spørgsmål til de frugt kyndige

Bruger den SATA?

Kan jeg udskifte dens OS med Windows XP eller Linux?

Vil den være en god maskine til Windows XP retro spil?

Kan jeg udskifte dens harddisk med en SSD?

Har den et 3D grafikkort?

Kan jeg udskifte dens DVD drev med fx en SATA baseret SD/CF kort læser eller lignende (kunne så bruge det gamle DVD slot i siden til at indsætte kort) ?

Hvis den ikke er egnet til at være maskine til retro xp spil så ville den stadig være interessant som Linux maskine
Gravatar #48 - Claus Jørgensen
6. maj 2020 18:09
#47

Hvorfor ikke bare køre MacOS? Du har stort set alt userland fra *nix / bsd som du har brug for.
Gravatar #49 - CBM
6. maj 2020 18:38
Dobbelt post
Gravatar #50 - CBM
6. maj 2020 18:39
Claus Jørgensen (48) skrev:
#47

Hvorfor ikke bare køre MacOS? Du har stort set alt userland fra *nix / bsd som du har brug for.

Kunne være interessant

Men jeg vil ikke til at skrive mac kode og det ville nok også kræve en nyere maskine alligevel

Dog ville jeg nok stadig gerne have en SSD i den... dens hdd er sata

Og dens pata DVD drev er ikke for godt. Den slugte en DVD som jeg ikke kan få ud

Var aldrig fan af slot-in drev

Men tænkte at jeg kunne koble noget andet på det pata interface... fx pata til sd adaptor og så lade det tidligere DVD slis huse adaptoren?

Den kan vel stadig bruge USB dvd drev?
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