Newsgroup: it.comp.os.amiga
Titolo: OS4: Logo e features ! LUNGO MA PROBABILMENTE INTERESSANTE...

 delle loro affermazioni...
Io no, non mi pare che si parli di compatibilità col passato, le
aggiunte riguarderanno solo i nuovi programmi probabilmente.
La cosa che mi spaventa di più sono invece i tempi... chissà se per
Settembre 2003 (notare l'anno...) uscirà qualcosa!
Ha ragione (anche se non completamente) Favrin quando dice che quelle
specifiche sono vecchie di anni (alcune di almeno 10 anni ;-)). Ve lo
dimostro, facendo fare due risate a qualcuno, informando qualcun altro,
e forse deprimendo i più ottimisti. Questo è un estratto dalle "idee per
exec" esposte alla
conferenza per gli sviluppatori del 1993 (notare di nuovo l'anno...),
tenutasi ad Orlando:
Advanced EXEC and CPU Issues
As we have seen, the pace of technology changes are getting faster all
the
time.  It is hoped that the Amiga and its applications will be able to
keep
up with these changes as best as possible.  This however means that
changes
will need to take place in both the Amiga's OS and in application
software.
---- Prima risata :-))
Memory pools are a way to help combat memory fragmentation, increase the
speed of the system, and give a simple way to keep associated memory
together.  Due to the fact that memory pools are "private" to the
application, a number of performance benefits are obtained (including
not
neededing to go into Forbid() during allocation or deallocation from the
pool).  Since pools give the system a simple way to keep your
allocations
together it also gives the system a simple way to release your
allocations
by just destrying the pool as a whole.  Also, the design was left
back-box
such that future system enhancements can be made to them without too
many
problems.  (A very important point here is that pools will be the memory
interface of choice in the future.)  For more information on the memory
pools, see the AutoDocs and the next AmigaMail.
--- seconda risata :-))))))))))
E ora, veniamo alla parte più divertente:
The Future
Now that I have talked about the major changes to EXEC for V39, we
should
look into what the future may bring.  What follows is a general
description
of the "vision" I have for the EXEC of the future.  They do not mean
that
exactly these features or that all or only these features will be
implemented.  However, it does show you some of the directions that we
hope
to be able to push the operating system.
----
Questo già aveva le "visioni"... andiamo bene...!
-----
One of the future features that is already somewhat in use is
CPU-specific
support libraries.  Currently, there is a 68040.library which patches
itself
into EXEC and the system to provide the functions needed to make the
68040
based Amiga work.  Future processors will also need such support
libraries.
As such, a goal will be to have a different library for each of the
processor
groups.  This library would take care of things like handling of the
various
processor specific issues such as instruction emulation, cache control,
MMU support, and other things that are system-level and CPU specific.
(In other words, there will be a 68060.library and maybe even a
68030.library)
----
Questo lo deve aver letto l'autore della mmu.library... ;-)))
----
Along with the CPU-based extentions, the much asked for and very much
mis-understood feature of virtual memory would become an issue.  The
design
(from the concept point of view) is rather far along at this point in
time
and now a number of changes to the memory system will make this
possible.
In order to prevent compatibility problems and other issues, the only
way
to obtain vertual memory would be to obtain a private pool with the
attribute of PAGED memory.  As a side issue, since it is only via
private
pools that such memory can be allocated, it may be possible to have
a form of protected pools too.
----
Ha appena risolto il problema di cui parlavamo prima...
----
Object oriented programming has become a major "key" word in the market
[...]
One need, however, is for objects that may not be user interface based
or
have any need for those aspects.  Example objects would be a data
retrieval
object or maybe a network link object or even a "thread" object.  In
fact,
given the correct core set of objects, a full resource tracking system
can be built out of just having objects dispose of their parts when the
"process" or "task" object is disposed.
----
Altre idee... visionarie, ma chiare almeno. A tutt'oggi l'unica
interfaccia ad oggetti del sistema rimane il BOOPSI.
----
The object support that I envision would be very low overhead support
for
runtime "linked" objects.  (Much like shared code libraries are runtime
"linked")  It would provide for both high-speed method inharitance and
complex multiple inharitance.  Disk loaded object classes and
application
embedded private object classes would both be supported.
In addition, the long-awaited task-tree (child-tasking) support is once
again on the list of things to do.  This would give tasks the ability to
be
notified about their children tasks (or parent task).  Some of this may
be well suited to the object-based "task" or "thread" construct.
Debugging support will also continue to get better.  Both via tools such
as Enforcer and via better support within the new constructs to check
for
and report invalid operations.  The hardest part of the developing a
major
application is the varification of its quality.  The system should be
able to help here.
-----
Il debbugging e un IDE..!! due cose importanti di cui pochi (oggi)
parlano, ma che all'epoca
visto il maggior numero di sviluppatori (e la migliore qualità di
essi...) era un problema sentito...
-----
Conclusion
So, while much work needs to be done just to keep up with other aspects
of
the Amiga OS and the hardware (including new CPUs) there are a number of
key issues/features that would make for an even better system.  Some of
these are good because they are great "PR" (everyone talks about getting
VM, even the 1-floppy A1200 owner who does not even have a MMU) and
others
are just very useful for system construction and simplified application
development.  (Debugging software on such a complex system can be a
pain)
----
L'hai detto....
Emiliano

 Settembre 2003 (notare l'anno...) uscirà qualcosa!
Qualcosa magari esce, ma per quando esce finirà come MiNT, o i sistemi
operativi alternativi per il QL -- sarà una specie di giocattolo che i più
useranno solo per passatempo...

 Scusa, ma l'alternativa quale sarebbe ? Non fare nulla ?
L'alternativa era fare qualcosa tanto tempo fa: AmigaOS4 avrebbe avuto senso
ai tempi dell'uscita della CyberStormPPC e della BlizzardPPC. Adesso è un
esercizio di futilità...
Ed anche ora potrebbero far di molto meglio, invece di stare a becchettarsi
l'un l'altro come i capponi che renzo portava ad azzeccagarbugli...

 della GDI (che senza DirectX, fa pena) 
Che giocherellone, non si stanca mai di scherzare :)
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 chiamate saranno più snelle e veloci.
Il problema, invero, è banale alquanto: la "nuova" libreria sarà uno
shared object stile unix -- se, quindi, potrà avere un segmento dati,
le variabili saranno raggiungibili per nome e prive altresì di un
layout preciso (i dati delle librerie "classiche" sono i campi di una
struct, e come tali raggiunti tramite un offset rispetto alla base), a
meno di non mantenere la struct LibBase ed offrire un singolo nome che
punta a questa struttura, ma in questo caso il passaggio a questo
"nuovo formato" è un puro esercizio di futilità... In caso contrario,
per creare "al volo" la parte dati della libreria serve, come minimo,
un meccanismo che catturi ogni accesso (tramite opportune protezioni
via MMU), traducendolo in accesso alle singole variabili del segmento
dati, con tutte le complicazioni del caso -- l'operazione è
tragicamente inefficiente, soprattutto in virtù del fatto che queste
nuove librerie non offrono alcun vantaggio significativo rispetto alle
vecchie...

 vecchie...
Perdona il mio parlare schietto, ma proprio non resisto a chiederti: che 
cretinate scrivi?
Puoi spiegarmi, per cortesia, cosa significa "creare al volo la parte 
dati della libreria"? Il segmento dati viene creato in fase di linking 
della libreria, non viene creato al volo.
C'è un thread su comp.sys.amiga.games di qualche tempo fa nel quale si 
tratta l'argomento.


 sarà sensibilmente più veloce.
Con la precisazione che i vecchi programmi non potranno usare le nuove 
librerie, tranne quelle di sistema per le quali è prevista la 
retro-compatibilità.


 compatibili sono contemporaneamente in formato vecchio e nuovo... 
Con il vantaggio che chi può si avvantaggia della maggiore velocità, e 
chi non può no, a scapito di qualche manciata di bytes in più nella 
libreria.
