Piattaforma (informatica): differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Refusi |
m Correzione typo (via JWB) |
||
(3 versioni intermedie di 2 utenti non mostrate) | |||
Riga 2:
[[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''',
== Descrizione ==
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 20 ⟶ 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
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 43 ⟶ 44:
===Piattaforma basata sul codice sorgente===
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>{{cita web|url=http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/ |nome=Michael |cognome=Simms |data=18 agosto 2009 |accesso=15 gennaio 2012 |lingua=en |titolo=Handling misbehaving libraries in binary products |citazione=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. |editore=[[Linux Game Publishing]] |urlarchivio=https://web.archive.org/web/20140222145251/http://blog.linuxgamepublishing.com/2009/08/18/handling-misbehaving-libraries-in-binary-products/ }}</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>{{cita web|urlarchivio=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 |titolo=Linux Game Development Part 2 – Distributable Binaries|nome=Troy |cognome=Hepfner |data=1º ottobre 2007|accesso=19 dicembre 2011|lingua=en |citazione=''Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]''|editore=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>{{cita web|autore=[[Ian Murdock]] |titolo=On the importance of backward compatibility |lingua=en |data=17 gennaio 2007 |url=http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |urlarchivio=https://web.archive.org/web/20120114153717/http://ianmurdock.com/platforms/on-the-importance-of-backward-compatibility/ |urlmorto=si |accesso=4 gennaio 2012 }}</ref><ref>{{cita web|url=http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|urlarchivio=https://web.archive.org/web/20040703024414/http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx|titolo=What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?|autore=[[Raymond Chen]]|editore=|data=15 ottobre 2003 |accesso=4 gennaio 2012|opera=The Old New Thing|lingua=en}}</ref> o [[Mac OS]], ad esempio.<ref>{{cita web|cognome=Peter |nome=Simon |titolo=AppImageKit Documentation 1.0 |lingua=en |data=2010 |editore=PortableLinuxApps.org |url=http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |urlarchivio=https://web.archive.org/web/20101129031656/http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf |urlmorto=si |formato=PDF|accesso=29 luglio 2011 |pp=
===Sistema operativo come piattaforma===
Riga 96 ⟶ 97:
* [[AMD]] [[Am29000]]
* [[Architettura ARM|ARM]]
* [[Atmel
*
* [[IBM
* IBM [[System/360]] e [[System/370]] ([[Metodo di indirizzamento|indirizzamento]] a 24 bit, 1964 e 1970)
* IBM [[System/390]] (indirizzamento a 31 bit, 1990)
* IBM [[IBM Z|System z]] (indirizzamento a 64 bit, retrocompatibile con System/390, /370 e /360, 2000)
* [[Intel
*
*
*
* Intel [[Architettura x86|x86]] (Intel 80x86 e processori compatibili)
** [[Intel 8086|8086]]/[[Intel 8088|8088]], [[Intel 80186|80186]]/[[Intel 80188|80188]], [[Zilog Z80|Z80]] e [[NEC V20|V20]] (parole a 16 bit con bus dati a 16 bit, spazio indirizzi a 20 bit con bus indirizzi a 20 bit, 1979)
Riga 113 ⟶ 114:
** [[x64]] o x86-64 ovvero AMD64 riferito al set di comandi compatibili con [[AMD Opteron|Opteron]] (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 Extension|AVX]], [[FMA (set di istruzioni)|FMA]], [[MMX]], [[Physical Address Extension|PAE]], [[Streaming SIMD Extensions|SSE]], uvm.
*
* 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|MIPS]]
Riga 125 ⟶ 126:
** [[Freescale ColdFire|ColdFire]] (Freescale, 68060-Design, dal 2004)
** [[Motorola Dragonball|Dragonball]] (Freescale, vormals MC68328 della Motorola, dal 1995)
*
* [[OpenRISC]]
* [[PDP-1]], [[PDP-4]], [[PDP-7]], PDP-9 e PDP-15 (18 bit)
Riga 143 ⟶ 144:
== Voci correlate ==
* [[Applicazione web]]▼
* [[Application programming interface]]▼
* [[Hardware]]
* [[Interfaccia (informatica)]]
* [[Piattaforma Java]]
* [[Software]]
* [[PaaS]]
▲* [[Applicazione web]]
▲* [[Application programming interface]]
== Altri progetti ==
|