NetSurf 2.6 ai nastri di partenza

Le nostre news in homepage

Moderatore: Newser

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 9:19 am

ShInKurO ha scritto:Si su Amiga il principale vantaggio di usare gli .so è proprio questo, e cioè che non hai i problemi di "non smontaggio" della libreria, dunque la coesistenza di più versioni in memoria della stessa libreria.

....

Appunto, stiamo dicendo la stessa cosa :ammicca:

Si ma non sono io che li critico ad ogni occasione. Il discorso è uscito (come al solito) perchè bisognava criticarli in ogni modo e come vedi hanno anche i loro pro.

Ecco, su questo non sono molto d'accordo, perchè appunto si perde il principale vantaggio di avere questo .so su Amiga: l'indipendenza dei pacchetti software dalle librerie globali e il grado di inquinamento del sistema... E se qualcosa va storto (come nel mio caso) non c'è alcuna differenza pratica nell'usare uno .so invece che una library Amiga (a meno che tutti gli altri programmi che usano i .so se ne freghino dell'installazione globale, ma Timberwolf fa assunzioni sull'installazione globale, e dunque...).

Si risolverebbe semplicemente creando delle cartelle locali. Almeno per adesso che tutto è in fase embrionale e sei sicuro che non hai problemi.

Insomma il punto è questo: se si vuole migrare o integrare meglio questi .so al sistema Amiga quantomeno bisognerebbe sfruttare le loro peculiarità rispetto alle library standard Amiga. In altre parole la possibilità di creare pacchetti software indipendenti dall'installazione globale, cosa che attualmente Netsourf e Timberwolf non fanno.
Si potrebbe chiudere un occhio e lamentarsi sottovoce se certe assunzioni le facesse solo Netsurf che è mantenuto da un programmatore di terze parti, ma Timberwolf è mantenuto da chi sviluppa il kernel di OS4, ergo da chi in teoria dovrebbe dare il buon esempio.
Se gli sviluppatori di OS4 si permettono di fare pacchetti software inquinanti lo stesso sistema che sviluppano beh, decisamente non si preannuncia una buona prospettiva futura per OS4. :riflette:

Esistono i bugtracker per questo e comunque stai parlando di un software (Timberwolf) che è in Alpha. Quindi se lo installi sai che ci sono dei rischi. Vale per tutte le Alpha dei software
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 9:29 am

afxgroup ha scritto:Il gatto che si mangia la coda :ammicca:
Non fare queste considerazioni alla Bill Gates e i 640Kb di memoria buoni per tutto :ammicca:

Io non sono rimasto nel 1990.. sono andato un po' più avanti anche se mi sarebbe piaciuto essere giovane come quegli anni..
Su OS4 esiste la memoria virtuale (...vabbè.. lasciamo stare i commenti..) e quindi io non mi preoccupo di caricare 4 librerie in più.

Gli sviluppatori di OS4 spingono verso gli shared object, attualmente due programmi (ma anche altri no?) presi in esame in questo thread li utilizzano. Consideriamo che in memoria tu abbia Timberwolf, OpenOffice, Thunderbird, un p2p che impiega i .so e un programma di chat basato pure sugli .so. Questo è un quadro abbastanza reale dell'utente. Consideriamo che ciascuno di questi programmi apre tre .so e richiede una versione differente di .so, totale .so in memoria = 16.

Se gli sviluppatori prendessero l'abitudine di compilare senza -g e senza -gstabs vedresti che le librerie sarebbero in media 2-300k. Moltiplica per 16 e vedi quanto sono grandi..

Consideriamo invece questi programmi che fanno utilizzo delle library Amiga nella versione OS4 (quindi con le interfacce, le quali come sappiamo permettono di avere diverse versioni delle funzioni di libreria in memoria, o almeno così dicono), quante library avrai in memoria? = 3.

Che per me fa un risparmio veramente infimo oggi nel 2010 e non nel 1990

Qual'è sempre stata la differenza tra un OS Amiga e un UNIX vantata in tutti i modi dagli amighisti, soprattutto dagli sviluppatori Amiga? È proprio quella di avere questo esiguo consumo di risorse, in questo caso di memoria.

Era la differenza del 1990 e non del 2010. Altrimenti perchè vuoi la memoria protetta, il resource tracking & co? Se installi WinUAE riesci ad avere un sistema 68k mostruoso e velocissimo che ha tutte le belle cose del 1990. Che ci fai ancora su OS4 non l'ho capito..

Tra l'altro come ti ha fatto notare guruman, AmigaOS attualmente è un sistema a 31/32bit, quindi io starei molto attento a usare nel 21esimo secolo questi .so prima di aver introdotto dell'hw e un kernel che supportino i 64bit...

E perchè?

P.S.: lo so, mi sono lamentato anche delle interfacce delle librerie su OS4, ma in questo caso rappresentano qualcosa di positivo rispetto a un possibile uso spasmotico degli shared object su Amiga.
[/quote]
Gusti..
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda m3x » mar ott 05, 2010 12:15 pm

guruman ha scritto:Ram Disk:> version png.library full
png.library 51.14 (16-Lug-2009)
using libpng 1.2.38

Questo è l'esempio perfetto, per mostrare la differenza tra MOS ed AOS4.1 per il porting di programmi, in quanto sul tuo sistema la libpng usata è la vecchia versione 1.2.38.

Attenzione, non sto facendo un confronto tra i due OS nella loro interezza, ma sto focalizzando l'attenzione solo su un aspetto particolare che è quello del porting di applicazioni.

Per far capire a chi non è programmatore, usiamo un esempio semplice, una persona ha deciso di portare una applicazione X che utilizza appunto la libpng.

Su MOS:

- prima di tutto occorre che qualcuno a monte abbia creato la png.library
- colui che ha creato la png.library avrà dovuto estrapolare il codice della libpng ed inserirlo in uno scheletro di codice che implementerà l'interfaccia della png.library, adattare anche gli eventuali applicativi di test che di solito accompagnano la shared library originale, creare i file include per gli sviluppatori, se la libreria è eventualmente fornita di default con il sistema operativo, andrà anche aggiornato l'SDK
- la persona che sta effettuando il porting dovrà modificare il codice che gestisce la libreria, che è già stato testato e debuggato sicuramente sulla piattaforma di origine dell'applicazione (che avrà come minimo 1000x utenti più dei nostri sistemi operativi amiga...)

ora mettiamo il caso che l'applicazione richieda libpng 1.4.x che offre delle features in più rispetto a quella utilizzata da png.library, cosa accade ora:

- o la persona decide di non fare il porting, oppure decide di "tagliare" dei pezzi di codice per evitare di usare le nuove features, od ancora contatta l'autore della png.library per vedere se è possibile aggiornarla
- se la png.library non è fornita di base, la persona che ha creato la png.library è ancora attiva ed è disponibile, allora non ci sono "molte" complicazioni
- se invece la libreria è fornita direttamente dal sistema operativo, occorre aspettare anche un eventuale aggiornamento del sistema e del SDK

Su AmigaOS4.1:

- colui che porta l'applicazione non deve modificare nessun codice, con risparmio evidente di tempo e di bug eventualmente introdotti con la modifica del codice
- se la libpng non esiste, oppure esiste ma non è aggiornata, può compilare lui stesso la nuova versione senza dover contattare nessuno ed attendere la nuova versione, nuovo SDK ecc (infatti su OS4depot si trova compilata una versione di libpng più nuova di quella fornita di base)
- nel caso specifico di librerie semplici come la libpng, sono sufficienti il più delle volte 3 semplici comandi: sh; make; configure; per avere compilate sia la shared che la link library

Ora, secondo me, è evidente anche a coloro che non sono degli sviluppatori, che l'approccio su AmigaOS4.1 facilita di molto il compito di portare nuove applicazioni, in quanto è il sistema operativo stesso che offre le infrastrutture necessarie.

Come riprova del fatto, non solo ci sono molti più porting per AOS4.1 di quanti ce ne sono per MOS, ma la validità dell'approccio su AOS4.1 è confermata anche dalla velocità a tempo di record con cui è stato possibile creare un datatype per il nuovo formato immagine WebP introdotto da Google, cosa che permette ad AOS4.1 ad essere tra i primissimi SO a supportare tali immagini (datatype che utilizza la libvpx shared library e che per ironia della sorte è stato creato proprio da colui che ha portato Netsurf su AOS4.1 e che qualcuno ha accusato superficialmente in questo thread di non conoscere Amiga OS...)

Il difetto delle shared library di non essere veramente "shared" in memoria viene ampliamente mitigato dal fatto che sui sistemi amiga attualmente difficilmente ci si ritrova in condizioni di scarsità di memoria disponibile (io con "soli" 512 MB sulla mia Sam non mi è mai capitato di ricevere un messaggio di "Out of Memory" e senza usare la swap tra l'altro)
Avatar utente
m3x

Admin
 
Messaggi: 2250
Iscritto il: mer set 10, 2003 11:30 pm
Località: Roma

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 1:59 pm

afxgroup ha scritto:Su OS4 esiste la memoria virtuale (...vabbè.. lasciamo stare i commenti..) e quindi io non mi preoccupo di caricare 4 librerie in più.


Se vabbè, se il sistema è capace di indirizzare solo 4Gb (in realtà 2) di memoria puoi avere anche un tera di memoria virtuale, non servirebbe a nulla. Ti ripeto, bisogna preoccuparsi nel 21esimo secolo su un sistema a 31/32bit di portare programmi di una certa entità e renderli non troppo esosi di risorse...

Se gli sviluppatori prendessero l'abitudine di compilare senza -g e senza -gstabs vedresti che le librerie sarebbero in media 2-300k. Moltiplica per 16 e vedi quanto sono grandi..

ti rendi conto che stiamo parlando di gente dentro OS4 e non gente di terze parti vero? :ammicca:
Se loro sono dentro e non danno il buon esempio è finita...

Che per me fa un risparmio veramente infimo oggi nel 2010 e non nel 1990

Il sistema può indirizzare totalmente 2Gb e nella migliore delle ipotesi (abbandonando la retrocompatibilità) 4Gb di memoria in quanto è un sistema a 32bit, c'è poco da girarci intorno. Su Windows esistono dei meccanismi particolari, supportati anche dal processore, che ti permettono di far vedere al singolo programma 4Gb di ram tutti disponibili solo per lui, ne avevamo già parlato. Su AmigaOS4 non c'è niente del genere che io sappia: sistema e programmi condividono uno spazio di indirizzamento limitato a 32bit.
Quindi io non la farei tanto facile...

Era la differenza del 1990 e non del 2010. Altrimenti perchè vuoi la memoria protetta, il resource tracking & co? Se installi WinUAE riesci ad avere un sistema 68k mostruoso e velocissimo che ha tutte le belle cose del 1990. Che ci fai ancora su OS4 non l'ho capito..

Ritorniamo allo stesso discorso: se OS4 non ha infrastrutture proprie più o meno moderne non credo si possa sentire la necessità di usare un simile sistema (nostalgia?). Se vai a basare un porting sulle infrastrutture che servono per il mero porting e poi non procedi a una migrazione del codice verso le infrastrutture native e originali del sistema allora non c'è alcun motivo di utilizzare quel programma su un OS alieno come AmigaOS quando lo stesso programma funziona meglio sul sistema in cui è nato...

E perchè?

Perchè un sistema a 32bit è in grado nella migliore delle ipotesi di indirizzare al massimo 4Gb di memoria. Nel caso di AmigaOS che deve mantenere la retrocompatibilità con funzioni che ritornano valori con assunzioni sul bit di segno si riesce a indirizzare la metà, e cioè 2Gb. Non importa se hai la memoria virtuale.
Sui sistemi moderni a 32bit si utilizzano dei "trucchi" che però si basano anche sul supporto dato dai processori.

Nel contesto dei dati "permanenti" su hd le funzioni sono state patchate all'inizio per supportare i 64bit (TD64 su MorphOS e l'altro standard integrato su OS4 di cui adesso non mi viene il nome) degli hd, cioè hd che fossero più grandi di 4Gb, ma c'eran comunque delle limitazioni sulle dimensioni delel partizioni e soprattutto dei file. In seguito (MorphOS2 e AmigaOS4.1) sono state create delle funzioni per il supporto dei 64bit nativo nei filesystem. Guardacaso quando i sistemi Amiga hanno introdotto delle reali funzioni a 64bit per i supporti di memorizzazione sono nati anche i filesystem a 64bit (SFS2 e JXFS su OS4 e quel filesystem nuovo su MorphOS che è uscito da poco).

La stessa cosa non si può fare con le funzioni di Exec perchè ti toccherebbe non riscrivere un filesystem o un lister come nel caso di OS4 e del wb, ma ogni programma che utilizza le vecchie funzioni. In pratica tanto vale che rompi la retrocompatibilità con le vecchie API.
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 2:36 pm

Beh, sono in trepidante attesa di software che necessitino quegli indirizzamenti. Netsurf usa si e no qualche centinaio di MB. Questo discorso non regge perchè se io decidessi di linkare tutto staticamente (e tu non lo sapresti mai o quasi) la situazione non cambierebbe. Prima delle .so nessuno però si lamentava che i programmi fossero grandi 11MB.. ora invece sono 3MB + 8 di .so. E dove sta la differenza?
Te lo ripeto. Un conto è pensare un software nativo su OS4 e a quel punto usi le librerie amiga per la parte amiga un conto è parlare di software nati su altre piattaforme dove fortunatamente non si fanno tutti sti problemi e usano librerie esterne e ben testate (curl, ssl, cairo, libpng, libjpeg etc etc etc) senza problemi.
Poi volendo fare i filosofi.. beh è un'altra storia. ma io non ho studiato filosofia
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 8:08 pm

afxgroup ha scritto:Beh, sono in trepidante attesa di software che necessitino quegli indirizzamenti. Netsurf usa si e no qualche centinaio di MB. Questo discorso non regge perchè se io decidessi di linkare tutto staticamente (e tu non lo sapresti mai o quasi) la situazione non cambierebbe. Prima delle .so nessuno però si lamentava che i programmi fossero grandi 11MB.. ora invece sono 3MB + 8 di .so. E dove sta la differenza?

Ma che c'entra l'occupazione dell'eseguibile o l'occupazione dell'exe+3 librerie con l'occupazione di n librerie di n versioni differenti in memoria e di cui magari n-1 di queste librerie fanno allocazioni di memoria maggiori rispetto all'n-esima?

Il mio discorso è generale, il tuo è specifico e limitato a un programma. Per la serie:"adesso abbiamo questo, domani vedremo, chissà...".

Io ti ripeto che i sistemi da cui vengono presi certi programmi per essere portati su Amiga hanno certe accortezze sugli indirizzamenti di memoria, su AmigaOS invece non ci sono questi espedienti. Quindi o AmigaOS si adatta e usa anch'esso gli stessi indirizzamenti (e quindi immagino dovrebbe anche migrare su un altra famiglia di CPU, ma non sono un esperto, sicuramente cdmauro e thekayneb ne sapranno di più... probabilmente anche gli ultimi PPC avranno questa possibilità, se non altro i G5), o quantomeno tenta di consumare meno memoria tendendo alla migrazione del codice portato sulle sue infrastrutture, che in teoria dovrebbero rendere il software meno esoso di risorse... Oppure si portano dei programmi di 10 anni fa che richiedevano meno risorse :semo:

Te lo ripeto. Un conto è pensare un software nativo su OS4 e a quel punto usi le librerie amiga per la parte amiga un conto è parlare di software nati su altre piattaforme dove fortunatamente non si fanno tutti sti problemi e usano librerie esterne e ben testate (curl, ssl, cairo, libpng, libjpeg etc etc etc) senza problemi.

Non si fanno problemi perchè ci sono le infrastrutture necessarie a reggere un simile carico... AmigaOS non ha al momeno un modo per indirizzare più di 2/4Gb di ram globalmente, gli altri sistemi hanno le loro accortezze in questo senso.

La situazione rispetto a 15 anni fa per AmigaOS non è cambiata: 15 anni fa non ci stava la memoria virtuale e la gente doveva uscire pazza perchè la ram costava un botto e dunque i programmi dovevano consumare poco.
Adesso l'architettura a 32bit classica non potrebbe sostenere certe richieste di memoria da parte dei nuovi programmi e quindi ci sono degli espedienti per utilizzarne più di 4Gb, in attesa della totale migrazione ai 64bit.
Questi espedienti non sono supportati da AmigaOS, il quale pur avendo adesso la memoria virtuale (che su un hw dove puoi facilmente montare 4Gb di ram facendo girare un sistema a 32bit risulta praticamente superflua), non avrebbe un modo per supportare più di 4Gb di ram.
Non ci sarebbe nulla di male (mah... :semo: ) se non ci fosse questa mania dei port abbozzati che richiedono pure più memoria rispetto alla loro controparte nativa sui sistemi in cui sono nati...
Il programmatore non Amiga continua a programmare tranquillo, il programmatore Amiga invece no :riflette:

Beh poi non mi venire a dire che: "sono in trepidante attesa di software che necessitino quegli indirizzamenti", perchè si sente spesso dire che ci sarà openoffice, ci sarà firefox4, ci sarà pincopallino.

Apri il taskmanager di XP con firefox caricato e una manciata di tab aperte su siti differenti, quanto occupa il tutto? A me al momento 300mb (su siti semplicissimi, mica portali di una certa grandezza eh!). Quindi solo Firefox (che sottolineamolo pure, è straottimizzato per Windows, mentre per OSX è praticamente abozzato ad esempio) si prende in memoria 300mb. Su OS4 supponiamo di avere 256mb di ram, il sistema inizia a swappare (e la swap di OS4 è pessima).
Supponiamo di averne 512mb si OS4, apriamo OpenOffice Writer, 2 documenti semplici, occupazione 150Mb. Siamo già a 450Mb di occupazione totale di due soli programmi. E il sistema quanto occupa in memoria?
Sia chiaro che gli utenti non si creano alcun problema nel tenere aperto questi programmi contemporaneamente e usarli. E insieme a questi programmi tanti altri. L'utente Amiga se potesse farebbe lo stesso.
Ecco dimostrato come il limite di 2Gb con questi programmi si senta forte e chiaro.

Tutto questo per farti notare come la tua assunzione sul fatto che ci sta la memoria virtuale, che puoi usare tutti i .so che vuoi al posto delle library/datatype amiga su AmigaOS non sia proprio corretta. Soprattutto nei confronti dell'utente che utilizza l'OS Amiga in memoria del suo esiguo consumo di risorse.

Su Windows invece Firefox si può permettere di consumare anche 2-3Gb di memoria, tanto il sistema gliene indirizza 4Gb (supponendo che ci siano più di 4 sull'hw), lo stesso parallelamente succede su OO.org e altri. AmigaOS non funziona così, ma alla vecchia maniera.
Poi volendo fare i filosofi.. beh è un'altra storia. ma io non ho studiato filosofia


Infatti non è filosofia, è analisi scientifica sulla quale si basa l'informatica. Quella stessa base su cui vengono progettati i sistemi in modo che non siano dei buchi.
La filosofia è un'altra cosa: è sostenere che Reaction sia meglio di MUI perchè è più leggero e più facile da programmare :scherza:
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 9:10 pm

Se mi vieni a fare ancora esempi con sistemi che usano 256MB beh.. allora è un altro discorso. Ma siccome già da anni su OS4 si possono raggiungere i 2GB senza problemi non vedo dove sta il problema.
Visto che (eccetto forse per MacOSX) la maggior parte degli OS sono a 32 bit perchè io devo stare a farmi tutte ste seghe mentali?
Su windows, Firefox non occupa 300MB. Forse quando lo apri e usi la pagina di google. Ma dopo qualche bella navigata su più tab si raggiunge il GB in poche ore. E' naturale che su un 8-core con 6GB di ram non te ne accorgi ma non per questo stanno a pensare a come guadagnare qualche kb. La differenza semmai è che hanno degli OS con la gestione della memoria virtuale migliore.
Vuoi fare la prova del nove? Prova a disattivare il paging su WIndows. Già quando premi su "OK" il sistema ti riconosce e dice "Shinkuro!!! Sei sicuro di quello che stai facendo?!!"
Forse non ti ricordi come era bello "leggero" Netscape Navigator quando c'erano i 133-200Mhz.. eppure non si stavano a fare tutti i problemi che ti fai tu.

Il programmatore non Amiga continua a programmare tranquillo, il programmatore Amiga invece no

Io programmo tranquillo invece. E' proprio grazie ai programmi mastodontici che ho scoperto dei bug sulla elf.library o sul pager ad esempio che se fosse stato per i programmi da 2k non sarebbero mai stati fixati.
non pensare che il programmatore Amiga sei tu. Magari sarai il programmatore Amiga "Classic" ma la programmazione non è sempre la stessa. Altrimenti su Win non avresti .NET e staresti usando le belle MFC. Leggere e che rispettano i paradigmi di Windows NT 4 al 100%

Infatti non è filosofia, è analisi scientifica sulla quale si basa l'informatica. Quella stessa base su cui vengono progettati i sistemi in modo che non siano dei buchi.

Buchi fino ad ora non ne ho visti.. Ho solo visto "filosofeggiare" e basta. Nulla di scientifico

La filosofia è un'altra cosa: è sostenere che Reaction sia meglio di MUI perchè è più leggero e più facile da programmare

La filosofia è anche dire che MUI è migliore di QT perchè ha la possibilità di iconificare le finestre alla maniera di OS4
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 9:17 pm

m3x ha scritto:Ora, secondo me, è evidente anche a coloro che non sono degli sviluppatori, che l'approccio su AmigaOS4.1 facilita di molto il compito di portare nuove applicazioni, in quanto è il sistema operativo stesso che offre le infrastrutture necessarie.

Qualcuno per caso l'ha mai negato questo? Non mi pare.
Come riprova del fatto, non solo ci sono molti più porting per AOS4.1 di quanti ce ne sono per MOS, ma la validità dell'approccio su AOS4.1 è confermata anche dalla velocità a tempo di record con cui è stato possibile creare un datatype per il nuovo formato immagine WebP introdotto da Google, cosa che permette ad AOS4.1 ad essere tra i primissimi SO a supportare tali immagini (datatype che utilizza la libvpx shared library e che per ironia della sorte è stato creato proprio da colui che ha portato Netsurf su AOS4.1 e che qualcuno ha accusato superficialmente in questo thread di non conoscere Amiga OS...)

Questo non fa che deporre ancora di più a suo sfavore.
Il difetto delle shared library di non essere veramente "shared" in memoria viene ampliamente mitigato dal fatto che sui sistemi amiga attualmente difficilmente ci si ritrova in condizioni di scarsità di memoria disponibile (io con "soli" 512 MB sulla mia Sam non mi è mai capitato di ricevere un messaggio di "Out of Memory" e senza usare la swap tra l'altro)

Dipende da quello che ci fai. Inoltre su AmigaOS la memoria si frammenta molto facilmente, e questo aggrava la situazione.

In ogni caso io sono contro l'uso anche di versioni diverse della stessa libreria shared.

Sì, sono rimasto fermo ai tempi di exec.library che esisteva in singola copia nel sistema per fare girare qualunque applicazione, fosse scritta per AmigaOS 1.0 o per il 3.9.

Questo se parliamo di AmigaOS, appunto.
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 9:20 pm

ShInKurO ha scritto:Io ti ripeto che i sistemi da cui vengono presi certi programmi per essere portati su Amiga hanno certe accortezze sugli indirizzamenti di memoria, su AmigaOS invece non ci sono questi espedienti. Quindi o AmigaOS si adatta e usa anch'esso gli stessi indirizzamenti (e quindi immagino dovrebbe anche migrare su un altra famiglia di CPU, ma non sono un esperto, sicuramente cdmauro e thekayneb ne sapranno di più... probabilmente anche gli ultimi PPC avranno questa possibilità, se non altro i G5),

Non ho capito bene quale sia il problema. Potresti darmi qualche dettaglio in più, in modo da poter fornire una risposta (se rientra nella mia sfera di competenza, ovviamente)?
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 9:36 pm

cdimauro ha scritto:Sì, sono rimasto fermo ai tempi di exec.library che esisteva in singola copia nel sistema per fare girare qualunque applicazione, fosse scritta per AmigaOS 1.0 o per il 3.9.


Non stiamo parlando di Exec ma stiamo parlando di librerie general purpose.
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 9:39 pm

cdimauro ha scritto:Non ho capito bene quale sia il problema. Potresti darmi qualche dettaglio in più, in modo da poter fornire una risposta (se rientra nella mia sfera di competenza, ovviamente)?

Volevo sapere se i ppc hanno qualcosa di simile al PAE degli x86, e se si, da quale versione dei ppc :felice:
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda ShInKurO » mar ott 05, 2010 9:43 pm

cdimauro ha scritto:Dipende da quello che ci fai. Inoltre su AmigaOS la memoria si frammenta molto facilmente, e questo aggrava la situazione.

La gestione della memoria su AmigaOS4 è cambiata radicalmente:

http://web.archive.org/web/200512301415 ... 22&Itemid=
Avatar utente
ShInKurO

Eroe
 
Messaggi: 1428
Iscritto il: dom mar 14, 2004 3:10 pm

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 9:55 pm

afxgroup ha scritto:
cdimauro ha scritto:Sì, sono rimasto fermo ai tempi di exec.library che esisteva in singola copia nel sistema per fare girare qualunque applicazione, fosse scritta per AmigaOS 1.0 o per il 3.9.

Non stiamo parlando di Exec ma stiamo parlando di librerie general purpose.

Non c'è differenza fra Exec e una qualunque altra libreria.
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda cdimauro » mar ott 05, 2010 9:58 pm

ShInKurO ha scritto:
cdimauro ha scritto:Non ho capito bene quale sia il problema. Potresti darmi qualche dettaglio in più, in modo da poter fornire una risposta (se rientra nella mia sfera di competenza, ovviamente)?

Volevo sapere se i ppc hanno qualcosa di simile al PAE degli x86, e se si, da quale versione dei ppc :felice:

Dipende dall'implementazione dell'MMU. Ce ne possono essere che arrivano fino a 36 bit di indirizzo fisico, come il PAE degli x86.

Mi preme sottolineare come già il 68040 avesse una modalità come la PAE, che permetteva d'indirizzare 34 bit di memoria fisica (quindi fino a 16GB di ram):

http://www.appuntidigitali.it/7305/moto ... azza-risc/
Avatar utente
cdimauro

Eroe
 
Messaggi: 2454
Iscritto il: mer giu 16, 2010 9:00 pm
Località: Germania

Re: NetSurf 2.6 ai nastri di partenza

Messaggioda afxgroup » mar ott 05, 2010 10:02 pm

cdimauro ha scritto:Non c'è differenza fra Exec e una qualunque altra libreria.


C'è differenza "teorica". C'era prima e c'è anche adesso. Perchè se ti rimpiazzavano exec.library ed era buggata magari non ti partiva l'OS ma chiunque poteva farsi un clone di ASL.library e metterlo al posto della tua e se per caso la tua aveva una versione diversa e/o era buggata per qualsiasi motivo tutti i programmi si sarebbero schiattati anche se l'OS partiva.
E' inutile che cercate di girarci intorno. Era così e sarà sempre così con le varie librerie shared e/o "amigose". L'unica soluzione possibile sarebbe linkare tutto staticamente.
Avatar utente
afxgroup

Admin
 
Messaggi: 3647
Iscritto il: ven giu 11, 2004 9:49 am
Località: Taranto

PrecedenteProssimo

Torna a News e rumors

Chi c’è in linea

Visitano il forum: Nessuno e 26 ospiti

cron