@wiffy as strange as it may seem we are now in near compl;ete agreement.

Point 1 -- yes I believe they are.

Point 2 -- yep I think this is what they have in mind and the problems of value adding are there also just as you describe. Now the amount of AmigaOS that makes it in has got to be an estimate, in itailly as I said just on a practical basis 90% would be my guess.

After that, well if the technology is a s good as I think it might be what we know as AmigaOS will be transformed quicky but over a few years at least.

In the end, that is in the end of a long line of development when we can speak of OS6, then I think there will be very little one to one comparison that can be made -- however, the general configuration, those things that make it distinct in look and feel will, if everyone does their job right will be there.

If the winds of fate are right AmigaOS may well ferry in a whole communication revolution. The philosophical term is sublate -- AmigaOS will if developed far enough sublate (negate itself but maintain and preserve its essence in a new form). All the rest wilkl then be retro--computing.

That is how big I think VP coding (and tiny tools) can go. Moroever, amigaOS is the pick of bunch to do this sort of thing, even if there had been no previous association. Plus I hasten to add this all takes time, even though things are moving at a much faster pace than they ever moved in the past.

Point 3 -- Yes it is important to know, how I wish for the days when Fleecy would come and unravel his thoughts, but they are gone with the trolls. I have an idea oin how we might be able to increase the information flow and quality (I am about to start working on that project) and you can see here on AW.net that DaveyD is doing a sterling job. But while I fully expect improvement I don't expect miracles at this stage.

Again I agree 100% with waht you are saying.

Poiunt 4 -- no real disagreement in a better world naming conventions and plans would go hand in hand, and we could all chart the progress and make suggestions that are productive. Maybe we can get that as well.

The actual way I see things evolving is that forms of compatibiility have to be there just to make the transition from 4-5. What those forms atrun out to be is another question. You concern is spot on, but the resolution has to be left for the future, whatever is said now by either any of us or even the Amiga Inc team is bound to be speuclative, such a big transition will set up nits own rules and problems.


PS I think now what causes so much anxiety in the community is the speed of comprehended change. OS4 is not even out and the next lot of changes are being spoken about. It gets confusing becuase it appears to tumble on unto the other. However in reality time will pass whenb we have the released OS4, and maybe a good year or two slip by while AmigaIc sorts its inhouse developments into a product.

That may be three years of OS4 reigning supreme, and another couple of years of running together do about five years to sort things into their final forms 2010 in otherwords.

My own timetable established some years back, is that by 2015 the whole game has got to change radically and unrecognisably (electronic commun ications), otherwise we will already have slid into technological chaos (the prevailing tendency).

A decade of MS dominance has really banked things up, the dam will break soon and, what ends up where, is going to be clear in just a few short years -- Amiga seems to be doing the right thing at the right time in my book.

_________________
Greg Schofield, Perth Australia

Quote:

Well first OS4 has been written to be as portable as possible,

It has been written to be portable accross hardware platforms, but the whole code is currently tied to the PPC. There are extensive PPC assembler parts in OS4, mostly in the low-level exec startup code, the interpretative emulator, and the JIT, to name just a few.

Even the 'C' code is partially CPU dependant. For example, all handling of MMU tables is in C, but of course, this depends a lot on the CPU.

So without porting substantial portions of the mostly low-level stuff, you won't get it to a new CPU easily. It doesn't mean it's impossible, mind you, just a lot of work.

What is possible is to port to a new PowerPC CPU. For example, it would be easy to move to a 64 bit CPU like the 970 using the 32 bit bridge (important detal!).

Quote:

with perhaps 10% from other sources.

No offense, but do you have the slightest idea how much code 10 % of AmigaOS is ? Let me tell you AmigaOS is _HUGE_, and 10 % of it is still a massive amount of code.


One other thing that you should consider: You want everything to be moved to VP. Are you aware of the implications you make ?

1. It's going to be slower than native code. Considering that everybody and his brother are complaining that the AmigaOne is not top-of-the-line anymore, this is a very important point to consider

2. VP code can only, by design, support the smallest common subset of CPU features. Things like Altivec, or even FPU can't be fully supported because Altivec is a PPC only thing, and FPUs differ (in features, like supported operations and the binary representation of floating point numbers). BTW, does anybody know if intent supports FPUs in the meantime ? It didn't when I last checked.

3. You say that an OS based on VP will be independant of the host ? Come on, that's the biggest mistake to make. Drivers do not magically appear out of thin air, and hardware (and host OS software capabilities) are not automatically used when they exist.

Bottom line: You have an oversimplified idea of the whole thing. This works for current intent technology because the devices they work on all have similar capabilities, and the CPU's supported also have similar capabilities (most embedded CPU lack "advanced" features like FPU's). Desktop users expect other things, though...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@Cecilia

"when the going gets tough, the tough get going.
That idea is what has kept me continuing even when really horrible things happened."

I prefer to find something more easier and enjoyable to do when that happends. But I think some of you got this whining thing wrong. If there hadn't been people whining in 2000/1 showning support for the OS probably AInc. and mostly Hyperion wouldn't have made up their minds. Maybe you wouldn't be using ImageFx today Garry himself admited that the whole thing went wront and the bot even cut off some parts of his answers.
It ended up nice, everybody can get their machines and keep coding more than ever.

Last edited by Jose on 22-Mar-2005 at 11:49 AM.

_________________

José

OK, good, now can I interpolate?

It seems to me that you accept there is a basis for the outstanding questions to be asked, even criticism and a basis for 'reasonable doubt' in any onlookers mind.

This is the crux of what I found a bit risible.

Some may have drawn outrageous conclusions from this 'reasonable doubt' ( such as AmigaOS4.0 is dead ) but others were not. I hope that now, looking back through the thread and at future threads that you won't lump those who went to one extreme with those that are viewing recent events with trepidation, concern or cynicism.

There is, in my view, good reasons to pick sides. The prime one being 'AmigaOS4 is here ready to use' and if we all support it, support it noisily and with developments, then if nothing else it will force the hand of those that might otherwise consider 'dead-ending' it to doing what you aspire to - of a near 90% retainment of technology in future products of the line.

Let me nail my colours to the mast now, if they were not already so obvious. I would much rather support Hyperion who has an AmigaOS4.0 successor ( with roots in evolved source code from earlire versions ) than Amiga Inc who does not have any ( yet ) successor to the Amiga Operating System on its portfolio in any form that I have yet seen demonstrated. I am AmigaOS4.x through and through, and in order to get me to encompass into that affiliation would have to be a successor technology that evolved either slightly or radically the Amiga Operating System.

Your mileage may vary, I do not dictate anyone elses opinions.

Dave.

Quote:

especially like this statement Quote: Don't panic

I'm not panicing this is just culture shock.

BTW: i feel reassured now of the amiga's future after this statement
thanks Mr G.

_________________
Win•dows: n. A thirty-two bit extension and graphical shell to a sixteen-bit patch to an eight-bit operating system originally coded for a four-bit microprocessor which was written by a two-bit company that can't stand one bit of competition.

@Rogue

>>Yes I have OS 4 running on an Amiga and elsewhere (that ought to start a new thread).

>wonder why this didn't happen yet

You're dying to tell us, aren't you?

hah finally may the headless chickens stop running about... Is it Sunday roast time yet?

_________________
Regards
Darren 'Ryu' Glenn
----------------------------
www.IntuitionBase.com - Your Guide to Amiga OS4.x and the AmigaOne
www.Bambi-Amiga.co.uk - My A1200 webserver, running 24/7/365

@GregS

I'm not an expert but I never understood all the bells and whistles some of you guys make of out of VP code.
Every half decent CPU out there has a half decent C/C++ compiler for it, and compiled code is gonna be faster and eliminate one unecessary layer. All the developers have to do is compile it, that's nothing.
The differences between platforms that make porting difficult are in the way OS fucntions are different and accessed diferently, from the OS itself to the HALs (Warp3d, DirectX etc...). This is where a uniform API warper layer could make porting easier and I believe that's partially what AInc. is doing. Actually on the targeted market standards are not yet well defined and that's an advantage that could be taken into account, with them establishing the standard (imagine if PCs Macs and Amigas all used the same Gfx HALs for example. )

Last edited by Jose on 22-Mar-2005 at 12:08 PM.

_________________

José

@turltle1
Quote:

turtle1 wrote: Well I'm glad to hear this news! Now if I can just get my Dad to update his website...

Fist of all i would like to say to AW.net (a thing i never got )

Then i would like to know who is your dad ? and what website are you talking about ?

Quote:

"4. Do I have AmigaOS 4.0, do I have an Amiga computer, do I know how to turn it on? And, if I have it, what do I think of it? Yes I have OS 4 running on an Amiga and elsewhere (that ought to start a new thread) [SNIP]"

Oh my god! and now what is this?

After AmigaAnywhere now appear AmigaElsewhere too??

Jokes aside, this is a breaking news!!

Last edited by Moly on 22-Mar-2005 at 12:39 PM.

@Entilzha

Quote:

1. It's going to be slower than native code. Considering that everybody and his brother are complaining that the AmigaOne is not top-of-the-line anymore, this is a very important point to consider

I don't see how VP code will be any slower than, say, C++ code. VP is a compiler. Unlike C++, it just compiles at load-time instead of at development-time. The C/C++ and Java languages are provided by translators, not compilers. They translate source code to VP tokens. It's these tokenized programs (aka 'tools') that are then recompiled to native code when the tool is loaded.

Quote:

2. VP code can only, by design, support the smallest common subset of CPU features. Things like Altivec, or even FPU can't be fully supported because Altivec is a PPC only thing, and FPUs differ (in features, like supported operations and the binary representation of floating point numbers). BTW, does anybody know if intent supports FPUs in the meantime ? It didn't when I last checked.

My v.1 SDK documentation seems to have both 32-bit (.f) and 64-bit(.d) floating-point types. These may or may not be IEEE types, but I expect the developers at Tao are aware of the differences. This would be taken care of in the CII (CPU Isolation Interface) written by Tao.

I have no clue how they would handle Altivec or SSE.

Quote:

3. You say that an OS based on VP will be independant of the host ? Come on, that's the biggest mistake to make. Drivers do not magically appear out of thin air, and hardware (and host OS software capabilities) are not automatically used when they exist.

Tao's site use to have a comment on it saying that Elate didn't need to be hosted. I don't know if it's still there. Ater looking at the Amiga/Elate documentation, I believe them.

When it is hosted, there's a defined API called the PII (Platform Isolation Interface). This would be similar to WINE in that it just translates the tool calls into native system calls.

BTW, I'm not a big fan of Elate/Intent/DE/AA, I just want to make sure there's no misconceptions about it.

_________________
Tony T.

People who generalize are always wrong.


1989 - 500 / 1991 - 3000 / 1997 - Genesis Flyer 1200T / 2003 - A1XE

These are the comments Amigans like.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@syrtran

Test's been made in the past. VP reached about 80% performance on average, depending on the circunstances, if I remember well...

_________________

José

Nickman

On behalf of the Amigaworld Team, a Belated to Amigaworld

_________________
No cause is lost if there is but one fool left to fight for it.

Quote:

Poster: EntilZha Date: 22-Mar-2005 20:38:26 @ glokraw

Quote:

Now as for guessing the mystery OS4 device, my guess is a. PPC based 'tivo' type mobo, already used in consumer devices, or b. PPC based server mobo, that is already used in business circles

Quote:

I could tell you, but then I'd have to kill you

5.11 Tactical Introduces the H.R.T. Tactical Ballistic Computer Watch

_________________
-vortexau, who's A1 XE-G4 remains at half-RAM !
A2000HD (from 1991) 060 64Mb PicassoII with OS3.5 . . . still working.

@Nickman

I guess You are not that good at looking at peoples profiles

My best guess would be that he is the son of Scott A Pistorino

and the website should be http://www.amigasource.com/

_________________
Best regards,
hnl_dk - Henning Nielsen Lund [Denmark]

Please send no PM to me, email me if you want to contact me. See you somewhere else.

@IonMane
Quote:

I am pretty sure Amiga Inc. has no rights to any code of OS4.0 except that which they have contributed to it.I am sure there are posts around to back this up, but I can't find them at the moment.

Not sure on that one, IP rights get really complex really fast. As for the rest I am mainly in agreement and that does tally with the immediate future. Wiffy and I were really going hammere and tongs about the long term, but I think things have settled down.

@EntilZha
I assumed 10% was a lot of code, because I assume a lot of coding has gone into it. This was just a guess of immediate exte3nsions that might be needed if the OS5 idea was put into effect, just to get a port. I assume that the code you have is probably 80-90% nice clean C, that the assembler heart of a few things while not massive in size is massive in concentrated work and design.

I personally don't think migrating to other CPUs will be done in the forseeable future, allowing for 64bit and some related "porting". It also seems to me that the OS4 PPC is here for a good long while whatever Amiga Inc plan to do in the future.

Now I have to be clear about my position. I am not argueing that OS4-OS5 should happen, in fact I have believed for some time now that hosting AA was the better option for the medium to long term. I want AA on OS4, I cannot see any beneifts to having a complete AA OS based on AOS4 or anything else. I simply do not know enough to have an opinion on that aspect of things.

I have an opinion on what Amiga Incs plans and directions are based on what has been said over a long period, and the bits and pieces being said now. My conclusion is that they do want VP OS based on your achievements of OS4.

Now you are in a better position to know than I am, but that is how I read things and I find it very difficult to read it otherwise.

Now I presume if they were given the source code tommorrow (not suggestiong that this may or might nnot be so) and with a good term of programmers, I think we would be waiting more than a year to see it, providing everything went well -- that is the size of the project in my estimation, big, big even to take nice clean C, rewrite the assembler, add in the extras and modify whatever with a decent sized team of talented people.

A year if everything went really really well (which it never does). So in response.

1. Yes VP is always slower, not greatly slower, but nopticebaly slower.

2. The reason I like hoisting as an option is I belioeve more of extra HW features may be available to VP through the host than VP being the OS.

3. I have no idea how Amiga Inc is thinking about drivers, that was the main reason I years ago abandoned any idea of a VP OS as such.

However, I have to modify 3, in terms of 1) not knowning AmigaIncs actual plans. 2 Maybe it is only some features they want and perhaps on specially designed HW configurations.
3. I have no proper idea of an internet OS could mean, presumable either AmoigaOS componants are wanted, or they want a tighter fit on the host.

I think I have confused a lot of people as to my advocacy (for AA as a hosted application environment) and analysis (where Amiga Inc appears to be going).

On the VP OS thing, my opinion is confined by my ignorance, I cannot se how it can be done for much the same reasons you outline, but I assume others have some better idea, because there certianly seems to have been a consistant move in that direction.

So I repeat I want AA on OS4 (especially the SDK) for a number of reasons I could argue. I believe AmigaInc want to develop some form of VP OS, more or less based on what has been achieved by OS4, but I have no idea how or why, besides which my opinion is that at the moment such a thing is of no interest - on this I hope to be proved wrong.

EntilZha by the way thanks for your reply, I learnt quiet a bit about how you put OS4 together - amazing work, and even more congratulations (my actual estimate of the project of OS4 developers is a stack of small printed (9point) A4 sheets of source code reaching two to three metres high -- am I close?

best wishes)

_________________
Greg Schofield, Perth Australia

@EntilZha

Quote:

Let me tell you AmigaOS is _HUGE_, and 10 % of it is still a massive amount of code.

Windows XP is HUGE , and 10% of it is still more massive than AmigaOS. AmigaOS is larger than it has ever been before, but compared to others it is still tiny.

Keep up the good work.

Last edited by DoodooHead on 22-Mar-2005 at 02:19 PM.

_________________
Amiga user since 1985.

@Jose

I must apologise to the thread for my grossly long and often used posts, I swear this will be the last one for a while.

Sorry mate. First as should be obvious -- I am no expert either. My background is in philosophy not technology, though I have been a user since Apple II was new.

Everybody sees types of source code as a matter of speed once compiled. Pick your horse and ride it as you will, it seems ridiculous to cause such a fuss about languages.

VP is not a language as such but a virtual CPU, the very nature of it means some loss of speed. It on the surface has very little to recomend it.

Porting is just one problem of cimputers (and perhaps not the most important). true with good standard C and C++ compilers and libraries you should be able just to compile for each CPU, OK and then for each OS that runs on a CPU and then.... well it simply does not work that way or all that well. Maintenance of code across platforms is unresolved, and I would argue unresolvable so long as you are compiling for HW and the the OS software that sits between it and a real world application, let alone the different configurations.

Compile once and run everywhere is nice, JAVA does it, ell to be honest pretends to do it, but not well -- in fact after all these years I consider a near complete failure on the promise it initially said it had.

OK VP does do and does it well for two features "hosting" (abstracting the HW SW layer through the hosted OS) and on the fly translation to an actual CPU, rather than filtering through pre-compiled objects such as in JAVA.

VP stands up damn well in otherwords from the crossplatform level and delivers what it promises because strictly speaking it really is not an OS, but an application environment.

Next complete opposed to JAVA, VP is a small tools architecture, this I really like. everything and I mean everything is brocken down into really small compiled tools each with their own light wieght interface. This is modulation at its best. A by-product of trnalsating code (you want it in small bits) but a very handy thinbgf for users and developers.

The tools are no more than subroutines and functions, each broken down, each addressable, each reusable. Thus scripts can talk to them. A nice Apps world in otherwords.

Now portability and small tools are nice, but neither is the real reason for going VP.

The real reason will sound strange but here it is --- software longevity.

Because the software is based on a virtual CPU it is impervious to instruction set change, the HW can change as much as it likes and it will always be possible to run the code. Likewise changes in OSes need hardly effect things, the App environment of VP code can be frozen (ie it can be further developoed and refined but still leave your functioning apps in a little bubble so thery can still be used.).

All of this is a by product of the portability, the small tool architecture, the parrtial OS of the App environment, all sitting on a small base - the CPU translations and the underlying OS communications layer.

JAVA is a big base, everything has to be regigged if JAVA moves from one platform to the next, very smalkl differences become in this context the most elusive of bugs, extensioon over ever more platforms, increases this incidious bug invasion, the problem is inherent in the broad based sdesign, regardless of any and that SUN tries to do control things eventual the answer is more specialisied objects and bulking out of the execution code.

VP is different, the narrow little base it stands on, is easily checked and already has abstracted things through the hosting OS ( in this JAVA is niether fish nor fowl). NBot only theoretically but bpractically VP means compile once run everywhere.

Now for Software Longevity and its sister concept Task Evolution.

Software does not last all that long for a number of reasons, the turnover in HW and OS are the main ones, but even here you can make special arrangements to keep running old solftware , but usually at the price of environmental coherence.

We don't think much about evolving our software usuage into the form of coherent tasks becuase at any time, the deck can shioft and software componants cease working, no longer will talk to other software and the lot on a failry regular basis dissolves into chaos.

We use to think of this improving software, however past a certian point adfding new features becomes a hazard and not a bonus, the improvement becomes a dissolution, and every year or so, we relearn a new piece of software to do the same old job.

Software has to have a longer life, not so that it stays the same for years but in order for it to evolve under the hand of the user (here small tools have an important role). It may be some insignificant part that survives, a routine that does not even do that much, but like the lynch pin once used to hold wheels onto the axle of a carriage, without it we stop every ferw kilometers and fix the wheel.

To evolve software to tasks, thus requires that like genetic code we have lots of little bits that by themselves do little but which can be mutated and changed, for this they must be able to live past HW changes and OS changes(because of the HW change if nothing else).


No amount of traditional compilied code, or JAVA can produce these features in software, and here we are talking about apps rather than an OS. VP code can, in fact it is inheret in its nature. Tao is good because they produced VP in the form it had to be in (unlike Sun's botched up JAVA). Amiga Inc is good because they are trying to produce more of the API side of things and harness talent to produce content, also because AOS4 is an ideal no-nonsense development platfrom for it.

So it might be slower, slightly more bulky, in its own little odd environment, it does not even have that many bells and whistles and it is not really a HAL but something else again
(an instruction set). And we really really need it, especially our developers, one compile and they sell on Linux, MS and perhaps Macs, and anything else.

_________________
Greg Schofield, Perth Australia

@ syrtran

Quote:

I don't see how VP code will be any slower than, say, C++ code. VP is a compiler.

Huh ? By your definition, a 68k JIT emulator should be as fast as any native code. It isn't.

VP is not a compiler. It's a _translator_. It's limited in what it can do.

A compiler can use a lot of time to optimize. VP can't. The VP loader probably does not optimized at all but just translates the incoming bytecode one by one. A C compiler optimizes on several levels, at the code generation level, and later on at the assembler level.

The last time I bnechmarked this, I had at least a 5 to 10 % performance loss due to VP. Don't know if it's better now, but it will _never_ reach the level of a highly optimizing C compiler generating native code.

Quote:

My v.1 SDK documentation seems to have both 32-bit (.f) and 64-bit(.d) floating-point types.

Irrelevant. Of course, VP supports floating point operations. That's not what I asked. I asked if it supports FPU instructions, i.e. does it use the on-chip floating point unit to execute the operations, or does it emulate them in software. That's a _big_ difference.

Quote:

, but I expect the developers at Tao are aware of the differences

Oh, of course, they know exactly what they are doing. However, since most small devices lack the FPU, they might as well leave it out, since supporting an FPU if all your targets don't have one is just added time, space, and money.

Quote:

Tao's site use to have a comment on it saying that Elate didn't need to be hosted.

Of course, Intent can run self-hosted. It wouldn't make much sense if you have a new device and first need to write an OS for the device, and then adapt intent to it...

But that does not make my claim void: You need drivers. This is especially true if you need to run self-hosted and can't even use an abstract driver interface on the host side.

All I'm saying is that a complety hardware agnostic system is a myth.You need drivers to drive the hardware. This starts with simple things like turning on the led on your PDA that signals new email, and moves up all the way to complex 3D drivers.

Quote:

When it is hosted, there's a defined API called the PII

The PII handles platform abstraction, that's true. However, the platform abstraction for an embedded device is rather small. Embedded devices have a fixed set of hardware available on board. However, these are likely to be different from device to device.

Take a PDA for example: They used ot have touch screens. Chances are that PDA 1 has one controller, and PDA 2 has another. Since these do not work automatically, you need a driver for both of them. Now add a PCI bus, which is common on desktop platforms. One user wants a Radeon, one wants an nVidia card. Drivers have to be available for those.

Bottom line, you need to write those drivers. That's why my assertion that a completely hardware independant OS is a myth.

Last edited by EntilZha on 22-Mar-2005 at 04:39 PM.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment