Intel föreslår x86S – förenklad arkitektur utan legacy-lägen

Och samma är det med vägar i stockholm och Göteborg. Bara att meja ner städerna och bygga nytt, då slipper man dessa konstgjorda andning som de håller på med för att lösa infrastrukturen.

Problemet är att mycket mjukvara pratar med hårdvara som är gammal, att byta ut denna hårdvara är precis som att bygga nya hus svindyrt. Vi pratar om fysiska maskiner får byggas om. Även om man anser kostnaden är liten så ha nere en fabrik länge är dyrt.

Och om man river skiten oxh bygger om, så om 5år är ens nya lösning gammal. Riv då och bygg om säger några.

Utvecklingen går emot att de tänker på framtidssäkra lösningar, men 32 bit är långtifrån utdött idag.

Men vilka kör 32-bitars operativsystem på ny hårdvara (som kanske kommer om några år)? Och om man gör det så varför?
32-bitars program kommer inte påverkas av detta så där är det lugnt.

Om programmet är skrivet i 32bit så går det att köra på en potatis i dagen mått med simulering så vet inte var du är rädd för.

Du vet väl att macOS både har en terminal och en högerknapp på musen numera? Det hände sådär för nära 25 år sedan om du missat det.

Även om MacOS blev "helt" 64-bitars för omkring 10 år sedan, så var det möljigt att boota om kärnan i 32-bitars läge för att få bukt med bråkiga drivrutiner och liknande.

Så jag håller inte riktigt med dig om att Apple skulle skita i det. Classic-läget, Rosetta och Rosetta 2 är tecken på detta.

Har kört med 3,5" floppy på min MacBook M1 här utan problem och har en fungerande Windows 3.11 i DOSBox. Äldre prylar än så har inte jag behov av att köra.

Så... meja ner städer..... istället för att använda gammal, osäker mjukvara... för att supportera t.ex sjukvården?

Ja... det.... är ett.... logiskt? resonemang..

Då är det mer rimligt att investera i fysiska maskiner som går att separera från mjukvaran, eller åtminstone köras med abstraktionslager som kan supporteras till framtiden.

Men det skulle aldrig någonsin ske. För då finns det ingens ficka som blir fylld av en fet muta.

Det man gör istället är att behålla någon form av teknologi som är 30+ år gammal och istället för att byta ut den mot en stor engångskostnad så förändrar man och anpassar man alla andra lösningar runt om den asgamla "core" teknologin.

Man gimpar sina nya system och man medvetet tar sönder dem för att kunna anpassas till något gammalt, för att då är det lättare att vinna nästa upphandling. Inte för att din produkt är bra, eller ens bättre. Bara för att det är din produkt som är kompatibel.

Kostymherrarna bjuds på en 899Kronors köttbit, på andra sidan jorden och råkar få ett odokumenterat brev i fickan med en fet ersättning nog för att tillåta denna skära idioti att fortsätta.

Om det inte skiner igenom tillräckligt så är jag teknikern! Det är jag som dagligen städar upp röran som orsakats av motstridigt bakåttänkande med kortsiktiga budgetar och kvartalsmål som inte räcker längre än nästa muta.

Det i sig cementerar mardrömmar som subscriptionmodels som t.ex Microsoft 365.

Lösningarna kan vara hur dyra som helst och hur dåliga som helst och hur inlåsta som helst för att det är inte den personen som skriver under som behöver bry sig, och han som signerar skickar notan vidare till nästa person som tar nästa kvartal ändå.

Örrk

AHEM, seems im loosing my mind here along the way!

Men de behöver knappast en processor från 2024 till sina 20 år gamla legacy program va? Så var ser du problemet egentligen?

Jobbigast blir det väl i tillverkande industri, i princip all CAD/CAM är idag baserad på x86. Många, speciellt här, är överdrivet positiva till övergångar till andra instruktionsuppsättningar än x86. Allt från vävstolar till cnc-maskiner sitter det x86:or i, ofta i förlegade OS. Ofta saknas källkod.

När kommer 128-bit?

Som tekniker kommer man såklart aldrig uppskatta gamla grejer som lever kvar på detta sättet.. Men nej det är inte dyrare om det inte är ett särskilt case, de flesta gamla grejer bara rullar tillsammans med sin maskin eller dyl.

Men ta tex ett sågverk, leverantören vill sälja ny såg och vägrar anpassa ny mjukvara till den gamla sågen, ny sågline kostar 3 miljoner. Just detta exemplet krävs väldigt lite av it för att hålla det vid liv och ett emulerat windows 95 tillsammans med comport löser biffen. Men även om det innebär en gammal dator är det fortfarande värt det.

I slutänden är det vad genererar det att köpa en ny dator ? Generar det inget som i detta exemplet och det innebär en ny maskin ja då är det många supporttimmar..

Det är nog av denna anledningen att Tåg som byggs år 2023 fortfarande drivs av Windows 95..
skulle vara för dyrt att uppdatera alla tåg en och en, samt byta hårdvara i dom till nyare.

man hittade något som funkade för ca 30 år sedan och har fortsatt med det sedan dess.
(exempel på tåg: X61 som numera åker i Väster och Östergötland.)

Nu räknar du som en entusiastisk myndighetschef.

Vi hade system som byggdes på 70-talet. I mitten av 90-talet började det talas om att det systemet snart kommer försvinna. Strax efter millennieskiftet försökte man introducera ett nytt system, men det var för dåligt. Några år senare hade man byggt om... med en frontend till det gamla systemet.

Det gamla systemet skrotades helt för ca 2 år sen. All funktionalitet är fortfarande inte ersatt och det finns andra gamla system som behöver uppdateras för att funka med det nya.

IT-utveckling har varit den största utgiftsposten under flera år.

Hur mycket det kostat totalt är omöjligt att säga men siffrorna lär vara på en nivå som ter sig overkliga.

Mycket väl skrivet förutom biten om mutor. Jag tror inte att mutor är en aspekt i detta, och jag ser fenomenet på alla företag. Det behöver inte vara ett beroende till gammal hårdvara.

Det är helt enkelt ofta väldigt svårt att inse att lite extra arbete eller extra kostnad idag för att ta bort något vi lider av kommer göra arbetet roligare, snabbare och enklare för många år framåt. Istället fortsätter vi behålla denna lösning till gammal hårdvara, mjukvara som bara kan underhållas av en person osv. osv. med motiveringen att vi inte har tid eller råd att göra det nu.

Jag brukar köra med att om vi inte vill investera i att hålla lösningen uppdaterad så avvecklar jag den istället.

Vi är i praktiken fortfarande "bara" på 48 bittars virtuell adressrymd. Några server-processorer stödjer 57 bittar. Men arkitekturen går upp till 63. (den högsta bitten brukar vara dedikerad operativsystemet)
Den virtuella adressrymden på ARM är också 48 bittar, och Apple M1 använder de högre bittarna för säkerhetsfunktioner (i alla fall i kärnan).

För data är SSE 128-bit. Men stödet för att använda det för att beräkna 128-bittars heltal är klent, och kräver en del tricks.
Minnessystemen läser 64 bytes i taget.
128-bit flyttal finns det standarder för, men praktiskt taget ingen hårdvara för däremot. x86 har sedan gammalt stöd för 80-bittars flyttal och jag tror det stannar kvar, men det används sällan numera därför att de instruktionerna är långsamma.

Kan väl fråga sig också när vi får äkta 64 bitars processorer.

https://www.phoronix.com/image-viewer.php?id=amd-ryzen-7900x-...

kolla efter "address sizes" så ser du att hetaste flagskeppet just nu enbart klarar 48 bitars adressering.

Angående 32-bit stödet i x86S. På Intels sida kring detta står det explicit att 32-bitars applikationer kommer stödjas på samma sätt som idag, d.v.s. via WOW64 på Windows. Däremot kommer endast 64-bit OS-kärna stödjas.

Om källkod saknas till programvara som fortfarande används betyder det nästan alltid att det handlar om programvara designad för gamla datorer och som idag kan köras på vilken potatis som helst, inklusive en RPi4 som emulerar x86.

För programvara där det finns källkod har det historiskt funnits fall där utmaningarna att porta till annan instruktionsuppsättning kunde vara utmanande. Men här får man väl säga att "Intel vann"...

De absolut mest komplicerade och därmed dyra problem att åtgärda handlar om skillnad byte-order och "unaligned memory access". Var ett helvete att få kod skriven av någon som aldrig använt något annat än x86 på t.ex. äldre Arm, MIPS, PowerPC, SPARC etc.

En sak man explicit såg till både vid designen av ARM64 och RISC-V var att röja dessa problem ur värden. Dessa är precis som x86/x86_64 little-endian och de tillåter läsning/skrivning "unaligned" (blir eventuellt en liten prestanda-hit).

Ovanpå det har program generellt sett aldrig varit så lätta att köra på vilken CPU-arkitektur som helst som idag då majoriteten av ny kod är skriven med Python, JS, Java (och en rad andra språk som använder JVM), C#, etc. Även kod skrivet med språk som Go och Rust är trivialt att porta, trots att dessa kompilerar direkt till maskinkod. Detta då man explicit sett till att undvika de saker som orsakar problem i portning hos C och C++.

Industrisystem har ofta två delar: dels något form av UI som helt saknar realtidskrav, den delen kan ju köras på "vad som helst" idag via emulering. Dels den realtidskritiska delen, den kör sällan x86 utan någon form av mikrokontroller alt. lite större embedded-system (historiskt ofta PowerPC eller MIPS, idag väldigt ofta någon Arm-variant).

Kan inget direkt om CAD, men såg att AutoCAD finns till MacOS och är portat till ARM64 (och det stod explicit att det är samma grundläggande programvara här både på MacOS och Windows). SoldidWorks går att köra via Parallels även på "Apple Silicon".

Historisk har det varit rätt utmanande att porta programvara (jobbade i nästan 20 år med RTOS som kördes på ett gäng CPU-arkitekturer, inklusive x86). Men idag är det långt enklare just p.g.a att både ARM64 och RISC-V är designade med tanke på att man enkelt ska kunna porta x86 kod dit.

CAD verkar primärt finnas på Windows, har svårt att tro det kommer ta mer än något år innan alla aktuella programvaror finns i ARM64 native version om/när Windows får någon relevant ARM64 HW att köra på (Microsoft verkar ju dels fila på någon egen plattform, sen verkar ju Qualcomms/Nuvias CPU väldigt lovande och den ska hitta ut i produkter under 2024).

Handlar det om Win95 saker med COM-port är det ju bara köra qemu-system-i386. Utöver att man då kan köra på vilket OS och vilken instruktionsuppsättning som helst bara det finns QEMU-stöd får man ju trevliga finesser som att kunna köra sin COM-port över SSH och liknade

Verkar dyrt/krångligt att försöka hita relik-HW för att köra detta på...

AutoCad körs under Rosetta i MacOS, att förvänta sig att något sådant skall ta något år när AutoCad inte rört sig 2 mm från WinTel sedan 1995 (utöver en MacOS-port sedan ca 2010) är lite väl optimistiskt.

Det pågår en del Oldschool under huven på AutoCad som gör det en pina att använda på moderna datorer, framförallt hur det berömda hårkorset ritas och pga är det möjligt att stänga av det eftersom prestanda på en toppspecad modern dator är som att simma i sirap. Nu har de ju officiellt gått över till DirectX 12 på windows men det är hopplöst buggigt och segt. I AutoCad används ofta 2d-mönster för att visa Zoner, material etc. Dessa verkar ritas av någon gammal Forth-turtle-graphics (this is how old I am) emulator på moderna Windows-datorer.

EDIT
Glömde kommentera SolidWorks on Apple Silicon.
Tillåt mig skratta högt av skadeglädje åt dessa stackars ingenjörsstudenter som köpte Apple-Silicon baserade datorer och har Solidworks i studieplanen.

Solidworks får definitivt kickbacks (av AMD och nVidia) för sk ISV-certifiering som enbart görs för de "Workstation"-klassade grafikkorten och envist vägrar låta mig inte veta detta varje gång jag startar SolidWorks.

EDIT2
Glömde också kommentera att AutoCad har en kärna, på detta finns anpassningar för olika branscher och roller. Detta katamari-nystan av kod gör det nära omöjligt att samarbeta i projekt med något annat än WinTel. Bäst stöd för CAD utanför WinTel har väl arkitektur där det finns en riktigt stark mjukvara, ArchiCad. För El, VVS, Kretskort och andra discipliner gäller extrem legacy-varning.

Nja, det nytillverkas t.o.m. 386/486-moderkort med ISA-kortplatser för industritillämpningar till väldigt rimliga pengar, så det är nog inget problem. Problemet är nog oftare att det är någon som i modern tid högskoleutbildat sig till sina datorkunskaper som får uppdraget att byta ut grejerna, och då framstår det antagligen som lika svårt att köpa nya 386-grejer versus att hacka ihop något på en helt annan plattform och försöka få det att fungera med alla anslutna system.

Det är ju inte nödvändigtvis så att det fungerar bara för att man lyckats plagiera koden heller, beroende på att systemets funktionalitet berodde på någon gammal hårdvarubugg som skapade en latens på rätt ställe. Sånt blir ju extra kul att försöka upptäcka 35-40 år efter att grejerna driftsattes.

Är medveten att det nytillverkas 486-kompatibla kretsar just för industribruk. Men finns det verkligen någon 386 tillverkning kvar?

Linux droppade stödet för 386 år 2007 då det inte fanns något relevant use-case kvar. Värt att notera att 2007 är samma år som Intel slutade tillverka sista varianten av 486, så den designen hängde kvar länge även hos Intel.

Man kan diskutera hur svårt det är att få tag i dessa, går faktiskt att köpa (möjligt kopior) på AliExpress. En officiell R8610 går lös på 49882 SEK.

För ett pris som får 4090 att verka billigt får man en 486-kompatibel CPU körandes på hisnande 133 MHz, PCIe-stöd, en UART och lite annat. Den stödjer hela 128 MB PC100/ PC133 RAM, det är dock inte inkluderat i priset!

Som jämförelse finns t.ex. Orange Pi 5, just den har PCIe-stöd (för t.ex. NVMe disk) och minst en UART. Relativt dyr SBC (1500-3000 kr beroende på konfig), men prestanda är då i nivå med ~10 år gammal bärbar dator, finns med 4 till 32 GB RAM. Denna drar antagligen klart mindre ström än ovan och kan vid behov emulera en 486 med långt högre prestanda.

Vidare får man mer I/O än ovan, går att konfigurera I/O för mer UART, SPI, I²C, GPIO, etc.

Uppenbarligen finns det ändå en marknad för att tillverka 486 kompatibla CPUer. Var prat om att döda 486 stödet i Linux i höstas, men man verkar ha lämnat det kvar och orsaken är antagligen just då det finns viss användning kvar. Det är besvärligt att ha något sådant gammalt kvar i kärnan, orsaker precis som för HW merjobb i form av underhåll.

Just att det finns sådana här saker gör det än mer vettigt att ta till något likt x86S. För egen del tycker jag det mest är ett för litet steg. Fattar naturligtvis varför Intel/AMD vill göra allt för att dra liket vidare, men resten av världen kan förhoppningsvis se fördelarna.

Som exempel: Ampere Computing (ARM64 tillverkaren som bl.a. Google, Microsoft och Oracle använder i sina datacenter) släppte precis sin nya plattform. Upp till 192 kärnor och inom 20 kW ramen (tydligen en, av flera, gränser man sätter för effekt i ett rack-skåp) och börjar inte x86_64 se lite trött ut? Notera att detta är mot AMDs Genoa med 96 kärnor, båda använder TSMC 5 nm

Edit:

Om man förlitar sig på sådana saker är man rätt rökt. De 486-kretsar som tillverkas idag är "kompatibla", det är inte Intel/AMD/Cyrix originalkretsar som nytillverkas. QEMU och andra emulatorer har dock i vissa lägen fått implementera specifika buggar i CPUer och HW just för att det ska vara kompatibelt, rimligen görs det även i "moderna" 486:or.