19 dec. 2025·8 min
Von Neumann och den lagrade programdatorn som möjliggjorde mjukvara
Lär dig hur idén om lagrade program — ofta förknippad med John von Neumann — möjliggjorde återanvändbar mjukvara, allmänna datorer och modern programmering.
Lär dig hur idén om lagrade program — ofta förknippad med John von Neumann — möjliggjorde återanvändbar mjukvara, allmänna datorer och modern programmering.
I kärnan av modern databehandling finns en enkel fråga: vad gjorde det möjligt för en maskin att utföra många olika uppgifter utan att byggas om varje gång? Tidiga elektroniska datorer kunde räkna snabbt, men att "byta uppgift" innebar ofta att man fysiskt ändrade maskinens konfiguration. Idén om lagrade program är den vändpunkt som gjorde datorer verkligen programmerbara.
En lagrad‑programdator förvarar instruktionerna för en uppgift (programmet) i samma slags interna minne som datan programmet arbetar med. Istället för att koppla om hårdvaran eller manuellt ställa om paneler kan du ladda en ny uppsättning instruktioner i minnet och köra en annan uppgift.
Det låter självklart nu, men det var ett djupt skifte:
Det här är inte bara en historisk kuriositet. Konceptet med lagrade program förklarar varför “mjukvara” finns som något skilt från “hårdvara”, och varför en uppdatering i dag kan låsa upp nya funktioner utan att byta chip.
I de följande avsnitten går vi igenom problemet tidiga datorer stod inför, vad tillvägagångssättet med lagrade program förändrade, de personer och dokument som klargjorde idén (inklusive den berömda EDVAC‑rapporten), och hur uttrycket "von Neumann‑arkitektur" kom att representera en ofta använd design.
Även om John von Neumanns namn starkt förknippas med lagrade‑programdatorer, är äran delad över ett bredare team och en era. Många forskare närmade sig liknande idéer samtidigt som de byggde de första praktiska elektroniska datorerna. Den här artikeln håller det sammanhanget i blick, eftersom förståelsen av teamarbetet hjälper förklara hur idén spreds så snabbt och blev standardmodellen för de flesta efterföljande datorer.
Innan idén om lagrade program kunde många tidiga datorer inte "köra mjukvara" på det sätt vi menar idag. De kunde räkna i imponerande hastighet, men att tala om för dem vad de skulle göra innebar ofta att man fysisk ändrade maskinen.
Ett vanligt tillvägagångssätt var att använda plugboards, patchkablar och switchpaneler. Operatörer kopplade ledningar mellan uttag, ställde rader av strömbrytare och justerade ibland tidsenheter så att signaler anlände i rätt ordning. "Programmet" var ingen fil du laddade—det var en temporär kopplingsschema.
Denna uppställning fungerade, men bar en dold kostnad: varje ny uppgift var ett litet ingenjörsprojekt. Om du ville ändra operationssekvensen (addera, multiplicera, jämföra, loopa) kunde du behöva flytta tiotals eller hundratals anslutningar. En enda felaktig kabel kunde skapa subtila fel som var svåra att diagnostisera, eftersom logiken var utspridd över hårdvaruanslutningar istället för nedskriven som läsbara steg.
Omkopplingen kunde ta timmar eller dagar, särskilt om maskinen behövde strömmas av, kopplas om och testas noggrant. Det innebar begränsad flexibilitet: dessa maskiner schemalades ofta för en typ av beräkning under längre perioder eftersom byte av jobb var så störande.
Föreställ dig en maskin uppsatt för att beräkna artilleritabeller—långa, repetitiva beräkningar med en fast formel. Om forskare sedan ville att samma maskin skulle lösa ett annat problem, som att sammanställa statistiska resultat för en folkräkning, var det inte ett snabbt "redigera programmet och kör igen". Operationsordning, mellanlagring och villkorskontroller kunde skilja sig och kräva en full plugboard‑omdesign och en ny verifieringsomgång.
Detta är världen som den lagrade‑programdatorn var avsedd att undkomma.
En lagrad‑programdator är en maskin där instruktionerna (programmet) finns i samma arbetsminne som de data programmet använder. Med andra ord behandlar datorn inte "vad som ska göras" som något separat från "vad som ska bearbetas"—båda lagras som bitmönster i minnet.
När tidiga datorpionjärer talade om minne menade de datorns snabba, direktanvändbara interna lagring—det vi idag mest förknippar med RAM. Det är platsen processorn snabbt kan läsa från och skriva till medan den kör.
Det skiljer sig från långtidslagring som en hårddisk eller SSD. En disk är bra för att behålla filer när strömmen är av, men det är inte den omedelbara arbetsytan som processorn hela tiden använder för att hämta nästa instruktion och uppdatera mellansteg.
När instruktionerna lagras i minnet blir det dramatiskt enklare att byta uppgift: du kan ladda ett nytt program i minnet och köra det utan att bygga om, koppla om eller fysiskt konfigurera om hårdvaran. Samma allmänna maskin kan göra löneräkning på morgonen och ballistiska beräkningar på eftermiddagen—eftersom "hur" jobbet utförs bara är en annan uppsättning bitar du kan byta ut.
Föreställ dig ett kök där receptet och ingredienserna förvaras tillsammans i samma skafferi. Kocken (processorn) går upprepade gånger till skafferiet (minnet) för att läsa nästa receptsteg (instruktion) och plocka eller uppdatera ingredienser (data).
Vill du laga något annat? Du bygger inte om köket. Du byter bara till ett annat recept—med samma bänkar, ugn och verktyg.
John von Neumann uppfann inte "datorn" och han skapade inte idén om lagrade program ensam. Det han gjorde—lysande—var att hjälpa till att omvandla ett lovande koncept till en tydligt formulerad, allmänt delad design som andra ingenjörer och laboratorier kunde bygga vidare på.
Von Neumann var djupt involverad i krigs‑ och efterkrigstidens datorprojekt, rådde team och skärpte den logiska strukturen i tidiga konstruktioner. Han hade en gåva för att förklara komplexa tekniska val i ett enkelt och organiserat sätt, och det spelade roll eftersom elektronisk databehandling utvecklades snabbt med flera grupper som löste liknande problem samtidigt.
Lika viktigt var att han skrev och spred inflytelserika beskrivningar av hur en dator kunde lagra programinstruktioner i samma minne som data. Denna tydliga inramning gjorde det enklare för andra att diskutera, lära ut och replikera tillvägagångssättet.
Namngivning fäster ofta inte vid den första personen med en idé, utan vid den vars beskrivning blir referenspunkten. Von Neumanns texter lästes, kopierades och citerades vida—så senare läsare associerade naturligt den lagrade‑program‑organisationen med honom.
Denna etikett förenklade också historien: det är lättare att säga "von Neumann‑arkitektur" än att lista varje bidragsgivare och rapport. Men genvägen kan sudda ut vad som egentligen hände.
Tidiga elektroniska datorer var ett kollaborativt, tvärinstitutionellt arbete som involverade matematiker, ingenjörer och programmerare. Konceptet om lagrade program mognade genom diskussioner, utkast, prototyper och revisioner i flera team. Von Neumanns bestående roll var att hjälpa till att kristallisera och sprida idén—att snabba på dess adoption—hellre än att ha skapat den ensam.
EDVAC (Electronic Discrete Variable Automatic Computer) var ett av de tidiga efterkrigsprojekten som syftade till att gå bortom "engångsmaskiner". Lika viktigt som hårdvaruinsatserna var beslutet att nedteckna designidéerna i en klar, delbar form. Då var datorbyggande fortfarande nära experimentell ingenjörskonst—kunskap levde i labbanteckningar, möten och i några specialists huvuden. En rapport kunde förvandla dessa spridda insikter till något andra team kunde diskutera, kritisera och återanvända.
First Draft of a Report on the EDVAC (ofta förkortad till "EDVAC‑rapporten") redogjorde i tydliga konceptuella termer för idén om lagrade program: en dator bör hålla programinstruktioner i samma slags internt minne som data. Det minnet är inte bara en plats att hålla tal medan en beräkning pågår—det håller också stegen som talar om för maskinen vad den ska göra härnäst.
Denna inramning får en dator att kännas mindre som en fix‑funktion‑enhet och mer som en allmän maskin som kan "omuppgiftas" genom att ändra vad som ligger i minnet. Du kablar inte om systemet för att växla från ett jobb till ett annat; du laddar en annan följd av instruktioner.
Förutom konceptet i sig hjälpte rapporten till att standardisera hur folk talade om datorer: minne, kontroll, aritmetik och in-/utmatning som distinkta funktionella delar som samverkar. Att ha ett gemensamt vokabulär och en vida läst beskrivning förklarade inte bara EDVAC—det gav hela fältet en gemensam modell för att bygga, jämföra och förbättra lagrade‑programdatorer.
Det är frestande att fråga "vem uppfann den lagrade‑programdatorn?" och förvänta sig ett enda namn. Men vetenskap och teknik fungerar sällan så. Idéer utvecklas ofta parallellt, förfinas i diskussion och blir först övertygande när de demonstreras i fungerande hårdvara.
John von Neumann är starkt förknippad med idén om lagrade program, men det tidiga arbetet involverade många personer och grupper:
En lagrad‑programdator är inte en enda insikt. Den kombinerar (1) det konceptuella språnget att instruktioner kan leva i minnet som data, (2) ingenjörskonsten att bygga pålitligt minne och kontrollenheter, och (3) programmeringspraxis som gör designen användbar. Olika personer bidrog till olika delar.
En annan anledning till att äran delas: att föreslå en idé är inte samma sak som att bygga en maskin som fungerar dag efter dag. Tidiga rapporter och diskussioner klargjorde koncepten; tidiga prototyper och produktionssystem bevisade att det var genomförbart. En noggrann historia respekterar båda sorters bidrag—utan att tvinga fram ett förenklat "första uppfinnare"‑domslut.
När folk säger "von Neumann‑arkitektur" pekar de oftast på en enkel, vida undervisad modell för hur en lagrad‑programdator är organiserad. Det är inte ett märke eller en enda historisk maskin—det är en bekväm etikett för en grundplan som visar sig i olika former över många datorer.
På konceptuell nivå ser bilden ut ungefär så här:
Nyckelidén är att CPU:n inte har en separat fysisk plats för "programmet" vs. "talen." Den hämtar allt den behöver från minnet.
CPU:n kör ett program genom att upprepa en loop som ofta beskrivs som fetch–decode–execute:
Denna beskrivning är förenklad, men fångar kärnan: programmet är en följd instruktioner lagrade i minnet, och CPU:n går igenom dem.
Att placera instruktioner och data i samma minne gör en dator allmänändamålsenlig på ett mycket praktiskt sätt:
"Von Neumann‑arkitektur" är bäst att se som en kortfattad beteckning för den lagrade‑programmodellen med en CPU, ett delat minne som håller instruktioner och data, och I/O—en idé starkt förknippad med von Neumanns tydliga förklaringar, även om den tidiga historien involverade flera bidragsgivare.
Folk talar ofta om "von Neumann" och "Harvard" som om de vore konkurrerande filosofier. De är egentligen två praktiska sätt att ordna programinstruktioner och data så att datorn kan hämta det den behöver.
I en von Neumann‑design bor instruktioner och data i samma minne och reser ofta över samma huvudban till CPU:n.
Det är konceptuellt enkelt: ett program är bara bytes i minnet, precis intill tal, text och bilder det arbetar med. Det gör också allmän programmering rakare—mjukvara kan laddas, ändras och lagras med samma mekanismer som data.
Nackdelen: när instruktioner och data delar samma "väg" kan de konkurrera om bandbredd. (Ibland kallas detta en "flaskhals".)
En Harvard‑approach håller instruktionslagring separerad från datalagring, ofta med separata vägar för att hämta respektive.
Den separationen kan göra det lättare att samtidigt hämta nästa instruktion och läsa/skriva data—bra i små, förutsägbara system. Ett enkelt exempel är många mikrokontroller, där programkod kan ligga i flashminne medan variabler ligger i RAM.
Moderna CPU:er ser ofta ut som "von Neumann" för mjukvaran (ett adressutrymme, en programmodell), medan de internt lånar Harvard‑idéer. Ett vanligt exempel är separata instruktions‑ och datacachar (I‑cache och D‑cache). För ditt program känns det fortfarande som ett minne, men hårdvaran kan hämta kod och data mer effektivt.
Det finns ingen universell vinnare. Von Neumann betonar enkelhet och flexibilitet; Harvard betonar separation och genomströmning. Många maskiner kombinerar båda för att balansera programmerbarhet, kostnad, effekt och hastighet.
En lagrad‑programdator gör inte bara beräkningar—den kan ladda en uppsättning instruktioner från minnet, köra dem och sedan ladda en annan uppsättning senare. Det skiftet gjorde program återanvändbara och delbara: ett program kunde skrivas en gång, sparas, kopieras, förbättras och distribueras utan att röra hårdvaran.
När programmet lever i minnet kan samma fysiska dator göra många olika jobb genom att byta instruktionerna den läser. Det är vad "allmänändamålsenlig" egentligen betyder: en maskin, många program. Datorn definieras inte längre av ett enda arbetsflöde; den blir en plattform.
Ett modernt exempel är din laptop som kör e‑post, spel och kalkylblad. Under ytan är det samma idé: hårdvaran är oförändrad medan olika lagrade program laddas och körs när du växlar appar.
När instruktioner behandlas som data i minnet blir det praktiskt att bygga mjukvarulager som hjälper dig att skriva mjukvara:
Dessa verktyg bygger på antagandet att program kan lagras, flyttas och manipuleras som annan information. Det gjorde mjukvaran till ett ekosystem snarare än ett engångsobjekt kopplat till ett visst kopplingsschema.
Ett användbart sätt att se den långa bågen: lagrade program möjliggjorde kompilatorer och operativsystem, som möjliggjorde moderna utvecklingsverktyg—och idag ser vi ett nytt abstraktionslager där du kan beskriva en applikation på naturligt språk och få verktyg att generera körbar kod. Till exempel är Koder.ai en vibe‑coding‑plattform där du bygger webb, backend eller mobilappar via en chattgränssnitt, med hjälp av LLM:er och agentbaserat arbetsflöde för att snabba upp vägen från avsikt ("vad ska den göra?") till körbar kod (källkod du kan exportera, distribuera och återställa via snapshots).
Resultatet är ändå detsamma: lagrade program gjorde bättre verktyg möjliga, och bättre verktyg gjorde mer ambitiösa program möjliga—vilket förvandlade datorer till flexibla, allmänna maskiner.
Idén om lagrade program gjorde datorer flexibla, men den belyste också en praktisk begränsning som ingenjörer fortfarande diskuterar: "von Neumann‑flaskhalsen." I vardagliga termer är det som en trafikstockning på vägen mellan CPU:n (arbetaren) och minnet (lagret).
I en typisk lagrad‑programdesign bor både instruktioner och data i minnet. CPU:n hämtar en instruktion, sedan de data den behöver, och skriver tillbaka resultat—ofta över samma förbindelse. Om den förbindelsen inte kan flytta information tillräckligt snabbt slutar CPU:n med att vänta, även om den i övrigt kunde utföra beräkningar mycket snabbare.
Två relaterade faktorer formar denna flaskhals:
En CPU kan utföra miljarder operationer per sekund, men om minnet inte kan leverera ett stadigt flöde av instruktioner och data blir prestandan begränsad av det långsammaste steget: att få in och ut bytes.
Detta är en väl diskuterad ingenjörsfråga, och moderna datorer använder flera tekniker för att minska påverkan:
Dessa metoder eliminerar inte den underliggande "vägen", men de hjälper till att hålla den mindre trång—så CPU:n spenderar mer tid på arbete och mindre tid på väntan.
Idén om lagrade program är inte ett museiföremål—det är hur vardaglig databehandling förblir flexibel. Dina enheter behöver inte "kopplas om" för att göra något nytt; de laddar bara olika instruktioner i minnet och kör dem.
På en telefon gör ett tryck på en appikon att operativsystemet laddar appens kod (instruktioner) från lagring till minne, och sedan exekverar CPU:n den. På en laptop händer samma sak när du öppnar en webbläsare, redigerar ett dokument eller kör ett spel. På servrar syns det ännu tydligare: maskinen kan köra tusentals varierande arbetslaster—webbförfrågningar, databasfrågor, bakgrundsjobb—utan att ändra hårdvaran alls.
Även funktioner vi tycker är "hårdvarulika" är ofta programdefinierade. Nätverksrouting, videodekodningsvägar, bildförbättringar och energihanteringspolicys uppdateras ofta via firmware och systemmjukvara—nya instruktioner, samma enhet.
Språk som Python och JavaScript körs ofta genom en interpreter eller en virtuell maskin. Istället för att CPU:n direkt exekverar din källkod översätts programmet till en strukturerad form (bytekod eller interna instruktioner) som lagras i minnet och körs steg för steg. Javas JVM, .NET, WebAssembly‑runtimes och webbläsarnas JavaScript‑motorer bygger alla på detta: instruktioner blir datastrukturer som maskinen kan ladda, flytta och exekvera.
Eftersom instruktioner är "bara" information försöker attacker ofta smuggla skadlig kod genom data—klassisk kodinjektion. Försvar som minnesskydd, kodsignering och icke‑exekverbara minnesregioner finns för att hindra otillförlitlig data från att behandlas som körbar kod.
Allt detta återknyter till det centrala löftet i lagrade program: flexibilitet genom mjukvara—nytt beteende på samma hårdvara.
När du tittar på en dator (eller läser en specifikation) hjälper dessa frågor dig att se den grundläggande modellen:
Om du vill ha fler lättillgängliga inlägg som detta kan du bläddra i /blog.
Not: Om du experimenterar med moderna sätt att omvandla "instruktioner" till körbara system—oavsett om du skriver kod direkt eller använder chattstyrda byggplattformar som Koder.ai—överväg att dokumentera vad du lär dig. Koder.ai erbjuder också ett program för att tjäna krediter för publicerat innehåll och hänvisningar, vilket kan vara ett praktiskt sätt att finansiera fler experiment och guider.
En lagrad‑programdator håller programinstruktioner i samma interna minne som de data instruktionerna arbetar på. För att byta uppgift laddar du en annan uppsättning instruktioner i minnet istället för att koppla om eller omkonfigurera maskinvaran.
Före lagrade program kunde många maskiner i praktiken "programmeras" med plugboards, patchkablar och switchinställningar. Att ändra operationssekvensen kunde innebära timmar eller dagar av omskoppling och omtestning, och en enda felkoppling kunde ge svårupptäckta fel.
Här betyder “minne” datorns snabba arbetsminne (mest likt dagens RAM) som CPU:n ständigt kan läsa från och skriva till medan den kör. Det skiljer sig från långtidslagring (som diskar/SSD), som används för att behålla program och filer när strömmen är av.
EDVAC‑rapporten beskrev tydligt organisationen där instruktioner och data delar internt minne, samt gav en användbar vokabulär för att prata om datorns delar (minne, kontroll, aritmetik, in-/utmatning). Denna klarhet hjälpte andra team att diskutera, jämföra och bygga liknande system snabbare.
Hans namn blev starkt förknippat med idén eftersom hans beskrivningar var mycket spridda och lätta att referera till, inte för att han var ensam uppfinnare. Tillvägagångssättet utvecklades av ett större samhälle av ingenjörer, matematiker och tidiga programmerare som arbetade med närliggande problem samtidigt.
Med "von Neumann‑arkitektur" avses ofta en modell med:
Det är en praktisk undervisningsetikett för organisationen med lagrade program, inte ett påstående om en enda historisk maskin eller ensam uppfinnare.
I en von Neumann‑design delar instruktioner och data ett minne (ofta med samma väg till CPU:n). I en Harvard‑design är instruktionslagring separerad från datalagring (ofta med separata vägar).
Många moderna system blandar de två—till exempel en minnesmodell för programvara men separata instruktions‑/data‑cacheminnen internt.
“Von Neumann‑flaskhalsen” är en prestandabegränsning som kan uppstå när CPU:n och minnet delar en begränsad väg för både instruktioner och data. Vanliga minskningar av problemet är cacheminne, prefetching och parallellism (som flera kärnor), som minskar väntetid men inte tar bort den underliggande begränsningen.
Eftersom program bara är information som kan laddas i minnet kan beteendet ändras genom att uppdatera mjukvara istället för att byta ut kretsar. Det är därför samma telefon eller laptop kan köra många appar, och varför firmware/OS‑uppdateringar kan lägga till funktioner utan att omdesigna hårdvaran.
Då instruktioner representeras som data i minnet försöker angripare ibland få system att behandla otillförlitlig data som körbar kod (t.ex. kodinjektion). Moderna försvar inkluderar minnesskydd (icke‑exekverbara regioner), kodsignering och andra kontroller som separerar "data du får läsa" från "kod du får köra".