Fleecy wrote:

Quote:

As far as AmigaOS3 is concerned we have to look at the business arguments for continuing to support it. We are of course interested in the views of the community in this respect. In short, we will end support for AmigaOS3 but it is a question of when.

I believe AmigaOS3.x support should be viewed in a light of making possible solutions such as Amiga Forever or maybe other classic AmigaOS emulation packages, at least if there is a big enough demand for this.

Quote:

Personnally I would go for a clean break, so software can progress without the chains of legacy support. (e.g. WinXP->Win95->Win3.1->Dos )

Note that MS has offered Win32S/WinG for Win3.1 for the transition to Windows 95. Win32S/WinG enables Win3.1 users & developers to run & build Win32S/WinG applications within Win3.1.
?Windows 9X? itself is a transition to "Windows NT". Windows 98 carries a subset of NT5 services to run and develop a section of WDM drivers**? sets.

**Use in Windows 2K and Windows XP/2003. The dotNET framework is use for transition to Windows Longhorn. Media Player 9 for Win98SE/WinME/Win2K/WinXP would be considered as a back port since it was a standard in MS Windows 2003.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Quote:

MooVid is planned for AmigaOS4.0.

What does that mean? Is the developer of MooVId or Hyperion going to do the port to AmigaOS4?

And is it gonna be included on AmigaOS 4 media or going to be a download from the authors web site?

Is it still gonna be shareware?

Thanx Fleecy, i think i new roadmap would be very much appreciated :) I can see the current one will cause a lot of confusion!

@ angrybrit

MooVId PPC is part of the AmigaOS4 Feature Set and thus will be included as part of AmigaOS4.

@MikeB

Can you anser my Question, since Fleecy doesn't seem to want to?

Fleecys just waiting for sunrise.

@ drebben

I believe an important part of the answer Fleecy replied to your question was:

Quote:

Another reason are code segments where response time is more important than execution speed, e.g. interrupts.

Within the feature list we can also see:

Quote:

68k emulation: both interpreting and JIT emulation available (see below), JIT for speed, interpreting for compatibility.

Basicly the few remaining 68k pieces (certainly AREXX until it is replaced) are not performance critical and thus you will not notice any difference with regard to the system performance if these pieces are either interpreted or not. Multimedia (3D, Video, Graphics, etc) related pieces are greatly dependent on execution speed, but these will all be PPC native in the final version anyway.

Obviously you will want the OS itself to be as stable and predictable as possible. For applications this could then be optional depending on the need for speed.

Basicly the interpreted emulation approach often results into better accuracy, you can compare this to WinUAE where the entire OS + applications are either entirely interpreted or using WinUAE's JIT engine. For instance you may have noticed that it's a good idea to disable the JIT engine when playing certain games to not have to deal with sound stuttering and graphic glitches when using WinUAE. As can be seen with MOS even without a JIT engine applications can run pretty fast, as MOS did not include a JIT engine until version 1.4.

So my guess is that these last pieces until they are fully replaced with native PPC implementations would be better to be interpreted.

Quote:

So my guess is that these last pieces until they are fully replaced with native PPC implementations would be better to be interpreted.

If you read my question, see that was not my question, or even georges question.

The question is:

HOW will OS4 be able to identify the diference between a peice of OS 68k code and a peice of non-OS 68K code, in order for them to be treated differently.

George explains it better than I do.

I don't care that some parts are interpreted and some parts are compiled, I just want to know how both systems of operation can co-exist.

@ drebben

AFAIK, the OS would not need to identify anything with regard to OS components as the OS programmer can do this him/herself in advance before releasing the OS. The OS components which are still 68k are already known and thus when they are called upon by the OS can use the interpreter by default.

I believe this separation will give better results as when the JIT settings are altered, this will not have an effect on the core operating system.

However when adding new yet unknown 68k or PPC components these are handled by the OS transparently (from a user point of view). Hans-Jörg Frieden has written an informative article explaining how ExecSG handles both PPC native and 68k libraries.

Quote:

I just want to know how both systems of operation can co-exist.

There is both an interpreter and there is Petunia (dynamic recompilation ) . Till the Pianeta show only the interpreter was used. So these are two seperate OS components which can work simultaneously within an multitasking OS.

Quote:

when they are called upon by the OS can use the interpreter

How? Can you see the technical issues here?

@ Drebben

Quote:

How? Can you see the technical issues here?

No not really, as what can currently be seen at AmigaOS4 demonstrations already does this, including even the still emulated graphics library. Petunia has also been demonstrated in public and is very fast.

@MikeB

Why do you keep going on about the speed of Emualtion, who cares? It's going to be faster than the fastest real Amiga anyway. IT'S NOT AN ISSUE!

But I don't see how some things can magically run in an interpreter and some things magically run in the dynamic compiler... who and what decides and how?

There are lots of things that don't add up here!

@ drebben

Quote:

Why do you keep going on about the speed of Emualtion, who cares?

Some do and some apparently don't. Please calm down as I am only trying to help you. You asked me, remember?

Quote:

But I don't see how some things can magically run in an interpreter and some things magically run in the dynamic compiler...

This Magic is called multitasking. I don't know which operating system you use at home, but on Windows you could for instance try to use two instances of WinUAE (or e.g. a Java, Basic interpreter) simultaneously, one with JIT enabled and one with JIT disabled.

Most of AmigaOS4 is already PPC native and other pieces are interpreted. Other software can run interpreted using the same interpreter as demonstrated for many months. Petunia is another emulator which can be used for its (faster, eh sorry...) JIT engine.

@drebben
Quote:

But I don't see how some things can magically run in an interpreter and some things magically run in the dynamic compiler... who and what decides and how?

I think the user will be empowered to choose what applications run under JIT and default to using the non-JIT emulator. How to enable the user to choose would be the only issue. A list of task names. A special tool type. A special symbol in the shell. There are many simple options to choose from.

Quote:

There are lots of things that don't add up here!

I suggest trusting Hyperion to do the best job they are able to do. They are Amiga fans and they will do what an Amiga fan would expect them to do.

If you absolutely must know, try emailing Hyperion directly. Email addresses can be found on their corporate web site.

_________________
ExecSG Team Lead

@ MikeB



That's great news! It's gonna be great for viewing DiVX (movies and anime).

Quote:

But I don't see how some things can magically run in an interpreter and some things magically run in the dynamic compiler... who and what decides and how?

The OS already has a lot of information about separate tasks (and even parts of tasks). For example, device drivers are loaded and run using a different mechanism to regular programs, and things like interrupts and callbacks have to be registered using specific system calls. I'm not involved with the OS4 project, so this is conjecture on my part, but if I were writing OS4, I would make use of that to decide which m68k engine to use. From the end user's point of view, it would be transparent.

"Any technology that is sufficiently advanced is indistinguishable from magic" -- Arthur C Clarke

I think one of the cam articles may answere this question... I've heard something on this topic in on of the articles floating around!

Shared Libraries in OS 4

I didnt read it all, i have before, but i cant remember... it describes the libraries and how it handles PPC and 68k libraries and how ppc and 68k programs can call any type of library!

I dont know if it answeres your question either at all or fully, but you may learn something that helps you get an idea of whats going on?

Quote:

HOW will OS4 be able to identify the diference between a peice of OS 68k code and a peice of non-OS 68K code, in order for them to be treated differently.

this is simpler than you think...

all 68k programs are in the usual Amiga Hunk format

all OS 4 PPC programs are in ELF/PPC format.

_________________
MicroSoft Game Studios ==

The loader takes care of it.

When code is loaded into memory, it's either loaded as m68k or ppc. These are put in different parts of memory (different mappings in the MMU).

When you jump to some code, it's location in memory decides whether to use the emulation or just execute.

Was that correct?

Edit:
Ah, I see you are asking about how to choose between interpreter and JIT. I haven't heard anything that suggests the interpreter will be used outside core parts of the system, so AFAIK JIT will be used for all user applications.

This is more fuzzy, though

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.