Piattaforma (informatica): differenze tra le versioni

Versione delle 22:02, 25 ott 2024

Versione attuale delle 16:31, 3 mag 2025

(6 versioni intermedie di 5 utenti non mostrate)

Riga 1:

[[File:Intel-core-i7-sandy-bridge.png|thumb|[[Processore]] [[Core i7|Intel Core i7]], esempio di piattaforma [[hardware]]]]

[[File:Gnome-2.20-screenshot.png|thumb|[[Linux]], esempio di piattaforma operativa]]

[[File:LAMP_software_bundle.svg|thumb|[[LAMP]], esempio di piattaforma [[software]]]]

Una '''piattaforma informatica''', abbreviatasi ancheriferisce cola termineuna dibase '''piattaforma''',oggetto sidi riferisce[[standard a(informatica)|standard una basedel standardizzatasettore]] su cui è possibile eseguire e sviluppare programmi informatici.

== Descrizione ==

Una piattaforma èÉ un componente di un sistema informatico ed è collegata ad altri componenti. Può trattarsi dell'[[hardware]] o deldi [[software]], in quest'ultimo caso ad esempio di un [[sistema operativo]], persinoo di un [[browser]] web]] e delledella relativerelativa interfacce[[interfaccia di programmazione]] o di altro software sottostante, purché il [[programma informatico]] venga eseguito con esso.

Gli altri componenti del sistema informatico in cui opera non sono visibili alla piattaforma stessa. Grazie a questa astrazione, una piattaforma può essere trasferita a diversi [[sistema informatico|sistemi informatici]] e funzionare correttamente. La complessità interna del sistema informatico viene aumentata con l'aiuto della tecnologia software, il che si traduce in un utilizzo semplificato da parte degli utenti umani.

Riga 21:

L'idea alla base di una piattaforma è l'[[Astrazione (informatica)|astrazione]] e la semplificazione.

Questa semplificazione può essere ottenuta fornendo allo sviluppatore dell'applicazione un modello funzionale che sia un'astrazione selettiva di funzionalità più concrete, realizzato in genere sottoformasotto forma di un'interfaccia di programmazione dell'applicazione ([[application programming interface|API]]), in cui è annidata la funzionalità sottostante. Per l'applicazione risultante, questa assume tipicamente la forma di un ambiente di ''[[runtime]]'' interpretato dinamicamente (ad esempio: [[Java runtimeRuntime environmentEnvironment|JRE]], [[browser]]) o di un [[Application binary interface|Interfaccia binaria per applicazioni]] (ABI) relativo a funzioni software note.

Una qualità che questi livelli di astrazione possono offrire è l'universalità, solitamente definita come [[compatibilità tecnica]]. Questa può riferirsi all'ampiezza, cioè alla quantità di dettagli diversi astratti, così come alla permanenza della piattaforma nel tempo. La compatibilità nel tempo può significare la garanzia di una compatibilità verso il basso quando una piattaforma viene ulteriormente sviluppata o la garanzia da parte del produttore che i nuovi “dettagli” astraibili (quali nuovi [[sistema operativo|sistemi operativi]], nuovo [[hardware]]) saranno integrati nella piattaforma non appena siano emersi (compatibilità verso l'alto).

Riga 33:

Una piattaforma per l'architettura di un processore utilizza un [[linguaggio macchina]] standardizzato, [[Parola (informatica)|parole]] di grandi dimensioni, un [[ordine dei byte]]. Un esempio di largo utilizzo è l'architettura dell'[[x86]].

Tuttavia, il modo in cui i singoli [[Instruction set|comandi]] di questo linguaggio macchina vengono elaborati internamente al microprocessore (ad esempio con [[Micro operazioni|Micro-op]]) può variare notevolmente all'interno della stessa piattaforma. Solo i risultati finali che i comandi forniscono rimangono invariati.

Le piattaforme hardware possono essere grossolanamente classificate in architetture [[CISC]] e [[RISC]]. Tuttavia, i confini tra questi due tipi di architettura stanno diventando sempre più labili nelle attuali architetture dei processori.

Riga 44:

===Piattaforma basata sul codice sorgente===

YoninbkokbhjOltre al concetto di piattaforma basato sulla compatibilità binaria, che consente la continua eseguibilità del software una volta creato, esiste anche il concetto di compatibilità attraverso la [[portabilità]] del [[codice sorgente]] di un programma applicativo. Questo non garantisce l'eseguibilità a lungo termine né un'ampia eseguibilità delle compilazioni dei programmi applicativi,<ref>{{cita web|last=Simmsy|dateurl=http://blog.linuxgamepublishing.com/2009-/08/18/handling-misbehaving-libraries-in-binary-products/ |nome=Michael |cognome=Simms |data=18 agosto 2009 |accessdateaccesso=2012-01-15 gennaio 2012 |languagelingua=en |titletitolo=Handling misbehaving libraries in binary products |quotecitazione=It is a bit of an arcane artform, making a game that runs on all Linux versions. […] [libraries] will load their own dependencies in a way we cannot control.The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn’t work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world. |publishereditore=[[Linux Game Publishing]] |archiveurlurlarchivio=https://web.archive.org/web/20140222145251/http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/|archivedate=2014-02-22 }}</ref>, quanto piuttosto il loro essere compilabili con un'ampia gamma di hardware, librerie di programmi e API software sottostanti, nota anche come indipendenza dalla piattaforma. Gli svantaggi sono che il processo di compilazione deve essere eseguito più frequentemente e soprattutto dall'utente o dallo sviluppatore dell'applicazione, un processo talvolta complesso e soggetto ad errori. Anche la creazione di software portabile per tale piattaforma rappresenta un problema.<ref>{{citecita web|archiveurlurlarchivio=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp |titletitolo=Linux Game Development Part 2 – Distributable Binaries|firstnome=Troy |lastcognome=Hepfner |datedata=1º ottobre 2007-10-01|accessdateaccesso=19 dicembre 2011-12-19|archivedate=2007-10-13|languagelingua=en |quotecitazione=''Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]''|publishereditore=gamedev.net}}</ref> Inoltre, la necessità di rendere disponibile il codice sorgente all'utente può rappresentare un ostacolo, poiché è insolito che un software proprietario non sia anche [[closed source|chiuso]]. Per questo motivo, il concetto di compatibilità basata sul codice sorgente è particolarmente dominante nel settore open source e nei sistemi operativi di tipo Unix, mentre la compatibilità binaria è dominante nei sistemi operativi Windows<ref>{{citecita web |authorautore=[[Ian Murdock]] |titletitolo=On the importance of backward compatibility |languagelingua=en |datedata=2007-01-17 gennaio 2007 |url=http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |archiveurlurlarchivio=https://web.archive.org/web/20120114153717/http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |archivedateurlmorto=2012-01-14si |offlineaccesso=yes4 gennaio |accessdate=2012-01-04 |archivebot=}}</ref><ref>{{citecita web|url=http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|archiveurlurlarchivio=https://web.archive.org/web/20040703024414/http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|titletitolo=What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?|authorautore=[[Raymond Chen]]|publishereditore=|datedata=2003-10-15 ottobre 2003 |accessdateaccesso=4 gennaio 2012-01-04|archivedate=2004-07-03 |workopera=The Old New Thing|languagelingua=en}}</ref> o [[Mac OS]], ad esempio.<ref>{{citecita web |lastcognome=Peter |firstnome=Simon |titletitolo=AppImageKit Documentation 1.0 |languagelingua=en |datedata=2010 |publishereditore=PortableLinuxApps.org |url=http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archiveurlurlarchivio=https://web.archive.org/web/20101129031656/http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archivedateurlmorto=2010-11-29si |offline=yes |formatformato=PDF|accessdateaccesso=2011-07-29 |archivebot=luglio 2011 |pagespp=2–32-3 |quotecitazione=''A critical distinction between the approach known from Windows and the Mac and the one known from UNIX and Linux is the „platform“: While Windows and the Mac are seen as platforms to run software on, most Linux distributions see themselves as the system that includes the applications.''}}</ref>

Oltre al concetto di piattaforma basato sulla compatibilità binaria, che consente la continua eseguibilità del software una volta creato, esiste anche il concetto di compatibilità attraverso la [[portabilità]] del [[codice sorgente]] di un programma applicativo. Questo non garantisce l'eseguibilità a lungo termine né un'ampia eseguibilità delle compilazioni dei programmi applicativi,<ref>{{cite web|url=http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/|first=Michael

Kj

Yoninbkokbhj|last=Simmsy|date=2009-08-18|accessdate=2012-01-15|language=en|title=Handling misbehaving libraries in binary products|quote=It is a bit of an arcane artform, making a game that runs on all Linux versions. […] [libraries] will load their own dependencies in a way we cannot control.The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn’t work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world.|publisher=[[Linux Game Publishing]]|archiveurl=https://web.archive.org/web/20140222145251/http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/|archivedate=2014-02-22}}</ref>, quanto piuttosto il loro essere compilabili con un'ampia gamma di hardware, librerie di programmi e API software sottostanti, nota anche come indipendenza dalla piattaforma. Gli svantaggi sono che il processo di compilazione deve essere eseguito più frequentemente e soprattutto dall'utente o dallo sviluppatore dell'applicazione, un processo talvolta complesso e soggetto ad errori. Anche la creazione di software portabile per tale piattaforma rappresenta un problema.<ref>{{cite web|archiveurl=https://web.archive.org/web/20071013034536/http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp|url=http://www.gamedev.net/reference/programming/features/linuxprogramming2/page2.asp |title=Linux Game Development Part 2 – Distributable Binaries|first=Troy |last=Hepfner |date=2007-10-01|accessdate=2011-12-19|archivedate=2007-10-13|language=en |quote=''Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]''|publisher=gamedev.net}}</ref> Inoltre, la necessità di rendere disponibile il codice sorgente all'utente può rappresentare un ostacolo, poiché è insolito che un software proprietario non sia anche [[closed source|chiuso]]. Per questo motivo, il concetto di compatibilità basata sul codice sorgente è particolarmente dominante nel settore open source e nei sistemi operativi di tipo Unix, mentre la compatibilità binaria è dominante nei sistemi operativi Windows<ref>{{cite web |author=[[Ian Murdock]] |title=On the importance of backward compatibility |language=en |date=2007-01-17 |url=http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |archiveurl=https://web.archive.org/web/20120114153717/http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |archivedate=2012-01-14 |offline=yes |accessdate=2012-01-04 |archivebot=}}</ref><ref>{{cite web|url=http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|archiveurl=https://web.archive.org/web/20040703024414/http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|title=What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?|author=[[Raymond Chen]]|publisher=|date=2003-10-15 |accessdate=2012-01-04|archivedate=2004-07-03 |work=The Old New Thing|language=en}}</ref> o [[Mac OS]], ad esempio.<ref>{{cite web |last=Peter |first=Simon |title=AppImageKit Documentation 1.0 |language=en |date=2010 |publisher=PortableLinuxApps.org |url=http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archiveurl=https://web.archive.org/web/20101129031656/http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |archivedate=2010-11-29 |offline=yes |format=PDF|accessdate=2011-07-29 |archivebot= |pages=2–3 |quote=''A critical distinction between the approach known from Windows and the Mac and the one known from UNIX and Linux is the „platform“: While Windows and the Mac are seen as platforms to run software on, most Linux distributions see themselves as the system that includes the applications.''}}</ref>

===Sistema operativo come piattaforma===

Riga 58 ⟶ 56:

A fini pubblicitari, i nomi dei marchi sono spesso riassunti in modo semplificato come piattaforme che in realtà sono tecnicamente differenziate. Un esempio ben noto è la “piattaforma Macintosh”, le cui piattaforme tecniche possono differire in modo sostanziale a seconda della generazione. Questa visione semplicistica è diventata in qualche modo parte del linguaggio e del [[senso comune]].

Ad esempio, l'azienda [[Apple]] si pubblicizza con la piattaforma “Macintosh” o “Mac”, anche se praticamente tutte le piattaforme che compongono Macintosh sono state sostituite (talora ripetutamente) nel corso dell'intero periodo della sua esistenza. Da un punto di vista tecnico, Macintosh è costituito e consisteva in piattaforme hardware e software molto diverse e talvolta incompatibili tra loro.

Infatti, nel corso della sua storia, il “Macintosh” ha utilizzato o utilizza [[680x0]], [[PowerPC]], [[IA-32]] o [[x64]] e [[ARM64]] dal punto di vista dell'architettura del processore. Le [[interfaccia (informaticcainformatica)#Interfaccia software|interfacce]] software e gli standard utilizzati dai sistemi operativi Apple sono o sono stati [[Carbon (API)|Carbon]], [[Cocoa (software)|Cocoa]], [[POSIX]], [[Single UNIX Specification|SUS]], ambiente software [[GNU]], [[Java Runtime Environment|JRE]], ecc.). Per garantire agli utenti una transizione agevole tra queste architetture, Apple ha utilizzato approcci transitori come i [[fat binary|fat binaries]] o i [[universal binary|universal binaries]] e gli [[emulatore di terminale|emulatori]] (trasparenti). Di conseguenza, l'intera famiglia di prodotti ha continuato a essere percepita dal pubblico come una piattaforma standardizzata.

Lo stesso vale per il marchio [[Windows]] spinto dalla [[Microsoft]]. Sebbene i cambiamenti non siano mai stati così estesi come nel caso del Macintosh, nemmeno Windows è una piattaforma standardizzata. Infatti, utilizza le piattaforme [[x86]] -[[IA-32]] e [[x64]]- e [[Architettura ARM|ARM]], in passato anche [[Architettura MIPS|MIPS]], [[POWER]] o [[PowerPC]], [[DEC Alpha|Alpha]] e [[Itanium]], e ha fornito o fornisce le applicazioni [[DOS]], [[Win16]], [[Win32]], [[Win64]], [[Native API]], [[Windows CE]], [[.NET]], [[POSIX]], [[OS/2]] e altre). Ad esempio, le API di Win32 e Windows CE sono compatibili solo in misura molto limitata. Tutti i prodotti Windows basati sul [[kernel]] DOS o Windows NT contengono diverse piattaforme, il che ha portato alla retrocompatibilità delle applicazioni fino a 30 anni in alcuni casi (come nel caso di Win16).

===Apertura===

{{MainVedi anche|Giardino recintato}}

I produttori di piattaforme hanno approcci diversi per quanto riguarda l'apertura o la chiusura delle loro piattaforme. Ciò riguarda, ad esempio, il modello di sviluppo, il modello di [[contabilità interna]] o il grado di apertura o libertà concesso all'uso ai diversi livelli.

Riga 77 ⟶ 75:

* [[AmigaOS]] ([[AROS]], [[MorphOS]])

* [[Android|Android Runtime]]

* [[Bada (Betriebssystem)|Bada]]

* [[Blackberry]]

* [[Carbon (API)|Carbon]] ([[Mac OS|Mac OS (Classic)]], [[macOS]])

Riga 88 ⟶ 86:

* [[OS/400]]

* [[Palm&nbsp;OS]]

* [[POSIX|Portable Operating System Interface]], POSIX (Unix/BSD, macOS, Linux, Windows&nbsp;NT, …)

* [[Single UNIX Specification]], SUS ([[Unix]], macOS)

* [[Symbian]]

* [[Windows API|Windows Application Programming Interface]]: Win16, Win32, Win64 ([[Microsoft Windows|Windows]], [[Windows CE]], [[WinOS/2]], [[ReactOS]], [[Wine]], …)

* [[z/OS]]

* [[VM/CMS|z/VM]]

===Hardware===

* [[AMD]] [[AMD Am29000|Am29000]]

* [[Architettura ARM-Architektur|ARM]]

* [[Atmel]] [[Atmel AVR|AVR]]

* [[Digital Equipment Corporation|DEC]] [[Alpha-Prozessor|Alpha]] (64-Bit)

* [[IBM]] [[IBM 801|801]]

* IBM [[System/360]] unde [[System/370]] (24-Bit-[[AdressierungMetodo di indirizzamento|indirizzamento]] a 24 bit, 1964 unde 1970)

* IBM [[System/390]] (indirizzamento a 31-Bit-Adressierung bit, 1990)

* IBM [[IBM Z|System z]] (64-Bit-Adressierung,indirizzamento compatibilea verso64 ilbit, bassoretrocompatibile con System/390, /370 unde /360, 2000)

* [[Intel]] [[Intel 4004|4004]] ([[larghezza dei dati]] a 8 bit con [[Bus (informatica)#Bus dati per tutti i tipi|Busbus dati]] a bit, 12-Bit-[[spazio indirizzi]] a 12 bit con 4-Bit-[[Bus (informatica)#Bus indirizzi|bus indirizzi]] a 4 bit, 1971)

* Intel [[Intel 4040|4040]] (larghezza dei dati a 4 bit con bus dati a 4 bit, spazio indirizzi a 13 bit con bus indirizzi a 4 bit, 1974)

* Intel [[Intel 8008|8008]] (larghezza dei dati a 8 bit con bus dati a 8 bit, spazio indirizzi a 14 bit con bus indirizzi a 8 bit, 1972)

* Intel [[Intel 8080|8080]] (larghezza dei dati a 8 bit con bus dati a 8 bit, spazio indirizzi a 16 bit con bus indirizzi a 16 bit, 1974)

* Intel [[Architettura x86-Prozessor|x86]] (Intel 80x86 unde kompatibleprocessori Prozessorencompatibili)

** [[Intel 8086|8086]]/[[Intel 8088|8088]], [[Intel 80186|80186]]/[[Intel 80188|80188]], [[Zilog Z80|Z80]] unde [[NEC V20|V20]] (parole a 16-Bit-Datenbreite mitbit con bus dati a 16-Bit-Datenbus bit, spazio indirizzi a 20-Bit-Adressraum mitbit con bus indirizzi a 20-Bit-Adressbus bit, 1979)

** [[Intel 80286|80286]] (parole a 16-Bit-Datenbreite mitbit con bus dati a 16-Bit-Datenbus bit, spazio indirizzi a 24-Bit-Adressraum mitbit con bus indirizzi a 24-Bit-Adressbus bit, 1982)<!--(16-Bit [[Protected Mode]], abwärtskompatibel zum 16-Bit-[[Real Mode|Real-Mode]] des 8086)-->

** [[Intel 80386|80386]] (parole a 32-Bit-Datenbreite mitbit con bus dati a 32-Bit-Datenbus bit, spazio indirizzi a 32-Bit-Adressraum mitbit con bus indirizzi a 24-Bit-Adressbus bit, 1985)

** [[IA-32]] bzw.o i386 (retronym auchretronimo x86-32) bezeichnetsi denriferisce zum 80386 kompatiblenal [[BefehlssatzInstruction set|set di istruzioni]] zahlreichercompatibile Nachfolger,con wiel'80386 e i suoi numerosi successori, demcome l'[[AMD Am386|Am386]] oder demo l'[[Intel 80486|80486]].

** [[x64]] bzw.o x86-64 ovvero AMD64 riferito al set di comandi compatibili con [[AMD Opteron|Opteron]] set di comandi compatibili (larghezza dei dati a 64 bit, spazio indirizzi a 64 bit<!--, compatibile con IA-32 e x86 a 16 bit-->; implementato da [[AMD64]] per i processori di AMD e [[x86-64|Intel 64]] e per i processori di Intel)

** numerose estensioni del set di comandi per IA-32 e x64, si veda<!-- in ordine alfabetico: --> [[Advanced Vector ExtensionsExtension|AVX]], [[FMA x86(set di istruzioni)|FMA]], [[Multi Media Extension|MMX]], [[Physical- Address Extension|PAE]], [[Streaming SIMD Extensions|SSE]], uvm.

* Intel [[Intel i960|i960]]

* Intel Itanium [[IA-64]] (larghezza dati a 64 bit, spazio indirizzi a 64 bit, non compatibile con IA-32 e 16-Bit x86)

* [[Architettura MIPS-Architektur|MIPS]]

* [[Motorola]] [[Motorola-68000er-Familie|680x0]] (dal 2004 [[Freescale Semiconductor|Freescale]], dal 2015 [[NXP Semiconductors|NXP]])

** [[Motorola 6800|6800]] unde [[Motorola 6809|6809]] (Motorola, bus dati a 8 bit, bus indirizzi a 8 bit, 1974)

** [[Motorola 68000|68000]] unde [[Motorola 68010|68010]] (Motorola, bus dati a 16 bit, bus indirizzi a 24 bit, 1979)

** [[Motorola 68008|68008]] (Motorola, bus dati a 8 bit, bus indirizzi a 20 bit)

** [[Motorola 68012|68012]] (Motorola, bus dati a 16 bit, bus indirizzi a 32 bit)

** [[Motorola 68020|68020]] e [[Motorola 68330|68330]] (Motorola, bus dati a 32 bit, bus indirizzi a 32-Bit-Adressbus bit, 1984)

** [[Motorola 68030|68030]], [[Motorola 68040|68040]] e [[Motorola 68060|68060]] (Motorola, bus dati a 32-Bit-Datenbus bit, bus indirizzi a 32-Bit-Adressbus bit, dal 1987)

** [[Freescale ColdFire|ColdFire]] (Freescale, 68060-Design, dal 2004)

** [[DragonballMotorola (Prozessorfamilie)Dragonball|Dragonball]] (Freescale, vormals MC68328 della Motorola, dal 1995)

* Motorola [[Motorola 88000er-Familie|88000]]

* [[OpenRISC]]

* [[PDP-1]], [[PDP-4]], [[PDP-7]], PDP-9 e PDP-15 (18-Bit bit)

* PDP-5, [[PDP-8]], PDP-12, PDP-14 e PDP-16 (12-Bit bit)

* PDP-6 unde [[PDP-10]] (36-Bit bit)

* [[PDP-11]] (16-Bit bit)

* [[PA-RISC]]

* Power

** [[IBM Power Systems|IBM Power]] (originariamente scritto POWER)

** IBM e Motorola (dal 2004 [[Freescale Semiconductor|Freescale]], dal 2015 [[NXP Semiconductors|NXP]]) [[PowerPC]]

* [[SPARC]]

* [[SuperH]]

* [[Virtual Address eXtension|VAX]] (32-Bit bit)

== Note ==

Riga 146 ⟶ 144:

== Voci correlate ==

* [[Applicazione web]]

* [[Application programming interface]]

* [[Hardware]]

* [[Interfaccia (informatica)]]

* [[Piattaforma Java]]

* [[Software]]

* [[PaaS]]

* [[Applicazione web]]

* [[Application programming interface]]

== Altri progetti ==