^^ Several interesting Comments on the SDK --------------------------------------- Adapted from the Moobunny Web Site SDK (Software Developers Kit) From the two reviews that I have read about it. One is positive from the ease of writting new sw while the other is negative from the point of view that it lacks hw optimisation and totally ignores standard hw issues like cache? From the first one it is difficult to say how fast it (the OS) runs while from the other it seems slow and sloppy (good for imbedded devices but not good for high bandwidth desktops). What are ppls opinions about the new Amiga OS (OE)? Will it be a good platform to use efficiency wise etc. Reply to this Remember that what people are looking at at the moment is running hosted and not native. i.e. there's linux underneath so you lose some perfomance there. Next if source is compiled to vp code then the vp translation engine needs to be optimized to use the underlying hardware (caches etc) and I suspect that at this stage, the vp engine is far from optimal for any given hardware as i'd expect that platform portability issues are at a much higher priority for Amiga and TAO than optimisation for any given cpu. Finally, i'd expect much of the component OS "tools" to probably be supplied with the SDK in vp code format as opposed to underlying hardware binaries. Expect a thriving cottage industry in native optimisations of tools for any given hardware. :) (Bunniers: I'm flying without a dev box here folks so keep me on the right track.) BFN Captain "Buying a new house at the moment so devbox purchase is on the long finger :(" Ron. Reply to this Re: SDK MIKE. mike@nospam.org. You've obviously never done assembly, the guy who gave the review about the deficiencies of the VP tao has designed is the more critical of the two reviews. As Amiga are encouraging folks to use VP for design of software (it's preferred), if it sucks, and the coder doesn't have control (too generic to retain the binary compatiblity), then what good is it frankly. Regards MIKE Reply to this Re: SDK Julian Kinraid. .. On Monday, Jul 3, 2000, Captain Ron wrote: > > On Monday, Jul 3, 2000, Anon wrote: > > > > From the two reviews that I have read about it. One is positive from the > > ease of writting new sw while the other is negative from the point of view > > that it lacks hw optimisation and totally ignores standard hw issues like > > cache? From the first one it is difficult to say how fast it (the OS) runs > > while from the other it seems slow and sloppy (good for imbedded devices > > but not good for high bandwidth desktops). What are ppls opinions about the > > new Amiga OS (OE)? > > Will it be a good platform to use efficiency wise etc. > > > > Remember that what people are looking at at the moment is running hosted > and not native. i.e. there's linux underneath so you lose some perfomance > there. Next if source is compiled to vp code then the vp translation engine > needs to be optimized to use the underlying hardware (caches etc) and I > suspect that at this stage, the vp engine is far from optimal for any given > hardware as i'd expect that platform portability issues are at a much > higher priority for Amiga and TAO than optimisation for any given cpu. I think people should try and look at the code that is generated (ie. when you run the program, the vp code is translated into the native machine code) before they worry too much about optimisation. And the mention of caches seems to about device driver code rather than normal programs. Once the vp code of a program is translated into machine code, the program will take advantage of instruction & data caches like any normal program will. So the speed comes down to how well vp code is translated into machine code, much like how a compiler (like gcc) tries to generate the best code for a given target. > Finally, i'd expect much of the component OS "tools" to probably be > supplied with the SDK in vp code format as opposed to underlying hardware > binaries. Expect a thriving cottage industry in native optimisations of > tools for any given hardware. :) (Bunniers: I'm flying without a dev box > here folks so keep me on the right track.) I'm flying without a dev box too, so everything I've said is an opinion and is not meant to be confused with actual facts :) Reply to this Re: SDK Captain Ron. rhill@interval-intl.com. Mike: WRONG! I have done assembly. :) Many years ago mind you. I used to be rather good with 6502 on my beloved Atari 800. Julian: You hit it right on the head. It's not the vp that runs it's the native code generated by the vp translator at load time. How good it does the translation can be worked at and tweaked by TAO but it leaves the programmer free to get on with vp coding. You can always drop down to native if you really need to (at the expense of portability). I can really see this being something that hobbyist programmers are going to love. Scenario. Program x runs on 10 different harware platforms under Amie/Elate and performs well but not optimally. Blink and viola! Fansite appears for program x offering native "tools" for speed enhancement in key sections of x for platform a. Not to be outdone, fans of platform b take advantage of processors specifics on their platform e.g. Altivec for PPC and a sort of fan based optimisation "arms race" ensues. :) BFN Captain "Not jumping in the street,wildly optimistic and drooling with happiness like EyeAm about AmigaNG but certainly leaning forward and rubbing my chin in a thoughtful manner as if watching a good Discovery channel documentary" Ron. Reply to this Re: SDKs, they OK, send away today greenboy. @bigsky.net. > Captain Ron : And howdy, Cap'n :  }  You replied to me here and I meant to reply back a couple weeks ago before being called away on a mission; hope you weren't put out. Sorry I can't recollect what the topic was, but your post was brilliant, I mean, like, absofargalutely stupendoculous. Sheeee-it... >Julian: You hit it right on the head. It's not the vp that runs it's the native code generated by the vp translator at load time. Right. >How good it does the translation can be worked at and tweaked by TAO but it leaves the programmer free to get on with vp coding. Yep. That's part of the design philosophy. I kinda wondered out loud why people were carrying on about absolute register control in Elate about a month ago for that very reason. And when I saw that "review" by JWK circulating, again I thought somebody is missing the point. In fact much of his review seemed off-base, and seemed to best function only as a counter to that drooly, vapid, non-critical, non-detailed virtual-parakeet-cage- liner review some other guy wrote a few days before that. The truth probably sounds a little something like this: Amiga Inc saw some commercial advantage, as did Tao, in partnering - after they evaluated the technical potential. Of which their is plenty. Tao made some unconventional choices in what tradeoffs were acceptable to bring their individual architectural vision to the forefront. With faster processors available it really shouldn't matter for most applications, went the reasoning. There are ALWAYS going to be compromises, QNX basically knows that to be a fact as well. In fact, QNX had considered making some of the same tradeoffs when brainstorming Neutrino. But they expressed individuality by choosing a different but similarly brilliant route - one that also considered that for all their OEMs, migration from QNX4x could be easier if they kept some continuity in where the majority of the system's abstraction was placed. Anyway, both these OSes have lots of personality and are well worth exploring, and I think, coding for. QNX has two disadvantages in the local neighborhood however: (1) The Name. People who can't think their way out of a turnstile can still blindly follow. Lots of emotion has been expended over the years in the name of the Name. Even those supposedly opposed to the Holders of the Name are swayed by its gravity and history. They too are drooling mightily like Bizarro World Pavlovians. This makes it tough to get QNX a fair shake or even a notice. Fortunately for QNX, they have major cachet elsewhere, and considerable adherents as well in the local developer community. (2) POSIX. 100% POSIX. No apologies, no excuses, no mumbling. This sounds like a huge advantage in the *nix domain - and it is. This and lxrun (Linux mapping layer, allows Linux apps practically non-penalized better-than-emu direct use) allow many porting strategies and along with QNX's Accessible Source model, a great app base in many categories. But to the casual purview it hides the radically different architecture QNX actually possesses. It hides the fact that the native API is much nicer and more modern, and that ports are not as cool as dealing directly with those APIs with clean, fresh efforts. It makes it look like another GeekOs (GeekIx?) of which we arguably already have plenty of. The non-discerning are not prone to look any deeper, or to notice that this is not a X-hobbled monster with recompile/install/code diarrhea. They aren't looking at POSIX as a strategic tool to be used when appropriate, but seem to misunderstand it as actually representing a certain monolithic design philosophy. So, where do we stood? ; }  We have two (2) rather misunder*stood* cutting- edge OSes that are ready to change the way we think about the desktop, and about pervasive devices and network computing. For developers they could be more fun than has been had for a long time. And with the right strategizing, there is already the potential for a lucrative involvement. But it will require, for some, the suspension of certain habits, prejudices, preconceptions. That infers replacing those practices with others; nature in general abhors a vacuum, at least where humans tend to live. This was true when Jay's Amiga first made its appearance. I remember reading early interviews with programmers that stated how tough it was to program without boundaries in view - fencelines that were formerly in clear view always on other systems, and that it was tough to come to terms with new possibilities... ...Well, this has turned into rather an article, than a reply, as many of my posts do. I hope some are enjoying the time spent; I *rarely* now ;  }  Anyway: All forward - Amiga, QNX, Phoenix developers - all of us! <-- greenboy ---<<<   did it feel good for you too?