mboost-dp1
Newz
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.
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.
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.
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.
Men bliver lidt spændende at se hvordan det kommer til at gå. Hvis det er strømeffektivt så er jeg da interesseret.
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.
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
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.
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.
... 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.
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.
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.
#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.
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.
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å.
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.
Det skulle ikke undre mig om de allerede har OSX kørende på ARM internt.
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.
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).
#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.
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.
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
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
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
*emperor palpatines voice* my hatred for Apple burns brighter than ever before... mwuhahhaha
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.
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.
#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...
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...
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.
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.
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."
#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.
#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.:
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.
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.
#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
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
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
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
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
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...
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.
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
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
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?
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund