From mint-bounce@lists.fishpool.fi Wed Dec 9 07:14:28 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=KFyYCGVOPKEkNR0MpbcDNDK0Xjzpy1M2V9xwuPxU9tU=; b=CAK8fYjkcR6HR0DHiQkKySHrNgAAemo55waRkM9+o/wcCFYEZypQuok3lAE19As7r7 W32LXflmbr97v9MRZM9L9mrRHy/2WvCmVWmB2gOv3XnpqZvqoAmKMF/703SiQhJ3rLDe ptovDToaExFcRQEatjd71c6HAqHy9o791Y0B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NKNJSMCrJhjh5Q6uoIUYlMUpq1TIwRzAFS+WMITYsgQ2hnhHKtmNOeHkiFEAkoynSI qACoar/aWDc0olWp+dDKVa1HyD16bo6vmP+Ak1PBOi5iIc9+92QThs4qOI7QkfHUXcue GLasne8VJeX3zo0CKmkRjdbGWNk1JG9vZ0xOQ= MIME-Version: 1.0 In-Reply-To: <7116AF0ECE9F4F099B489E49FEE856FC@mercatus.local> References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <11a6f2b10912081349x51b88c71p278c085ff9b77f2e@mail.gmail.com> <11a6f2b10912082333g5ede94a6t862ff00a111c970a@mail.gmail.com> <7116AF0ECE9F4F099B489E49FEE856FC@mercatus.local> Date: Wed, 9 Dec 2009 23:08:59 +1100 Message-ID: <11a6f2b10912090408t4d8c9874h12fa44026a463178@mail.gmail.com> Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 From: Paul Wratt To: mint Content-Type: text/plain; charset=ISO-8859-1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: paul.wratt@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Jo, oth you and Helmut a missing some crucial point that are side affects of add "certain custom ASM function".. On Wed, Dec 9, 2009 at 7:54 PM, Jo Even Skarstein wrote: > -------------------------------------------------- > From: "Paul Wratt" > Sent: Wednesday, December 09, 2009 8:33 AM > To: "mint" > Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 > >> For anyone else who is reading this, and has not read my latest post >> in ARAnyM list (or related ACP list posts), I am proposing the same >> additions of ASM to XaAES (along with full AES implementaions) to be > > I think this is a very, very bad idea. The goal should be to get rid of > assembler, not add more. I can't see how the future development of the AES > can benefit from obfuscated assembly code which ties it to a single CPU. I > programmed a lot of 68k and 6502-assembler in the 80's and early 90's, and I > don't intend to do that again. > no body is asking you to, and once they are set, there should be no need to modify them. Of they become that outdated, they can (again) be replace by C functions > I can see the benefit in assembler if you try to optimize a line-drawing > routine - but there are no such things in the AES. The AES is separate from > the hardware, and thus should contain no hardware-specific code. And > assembler is 100% hardware specific. It belongs in device drivers and > nowhere else. When it comes to performance, well designed (and implemented!) > algorithms in C are hard to beat. For such a big project, the compiler will > for sure optimize the code better than yourself. > The people on this planet who can write "algorithms in C that are hard to beat", usually have an excessive understanding of ASM (or how ASM is written in binary for, and executed at run time), and are as common as "hens teeth". This is not to say "none of those people are with earshot of this thread", but as you your self know writing good clean fast, or better still exceedingly fast, algorithms is actually quite complex, and may require much code rewrite, and tests for all situations. The fundamental flaw in your vision (and many others peoples who blow "only high level languages" trumpets), is that C is compiled into hex byte codes, when these are "read in an english/language style" they are called assembly instructions (as seen in any debugger - assembly numonics). The "side affect" I mentioned at the top, is that any ASM that is included in current OS development, will then require v4e compatible compilers, and this is a fundamental is that will probably be one of the "last" things ever looked at, as no doubt Henk will attest to when he has completed AHCC for Coldfire platforms. That level can make even a delve in to the kernel by experienced programmers look like "a stroll in the part with you grand mother", hell even a lot of good ASM programmers wont go there.. What is AES if not a Window Frame and Widget render driver? What part of "interacts with screen layout and graphics rendering" is not covered by "algorithms dealing with bitmap textures, 3D work, an RGD color related graphics". What part of a color palette is not manipulated but extremely hispeed algorithms in ASM as used in demos, and since when do demos not include "bitmap", "texture", "vector" and "effects" ASM routines that are highly (even tortuously) speed orientated while maintaining visual quality > I think the effort should be put into bug-fixing, then adding more features > (add some missing 4.1-features, MagiC-style scrollable editfields and the > edit-object) and finally work on the visuals. First make it more stable, > then more feature-rich and finally make it look better :-) And do it all in > C so the work can be continued when you loose interest or for other reasons > have to drop this project. > This is already being done, and within a short period of time wee will see some concerted updates available from CVS, and a point release "for the rest of use". I imagine full AES 4.0 will be some time in coming, as will full 4.1, as this requires much research, and cross referencing, and more so, testing, as mostly this is about compatibility, not wheather it performs in a bug-less way. This is stuff I am interested in, and have no problem in assisting with, even if it is just compatibility testing or function return research.. however not everyone is upt to the task, and as has already been note in recent posts related to VDI, document tation is just not enough.. The part you must remember "many hands make light work" and "too many cooks spoil the broth". ATM the means Helmut is doing bug fixing, and if he was to continue solo, he could also take you path or additions, then finally visuals. As I have pointed out before, I prefer that if my desktop or app is going to crash, then it can at least do it in style. As I have already proven, even someone inexperienced in C can add the visual fluff that makes this possible, with out impacting on current binary size or memory usage, or config compatibility. In my mind, this should have been done years ago, but I am doing it now, so that is a moot point, it was obviously not possible before, based on the fact that anyone "touching" XaAES would have to do some bug fixing as well, and that can put off many people. I am lucky in that I do not have to worry about bug fixes in XaAES as Helmut is already on the job. With the increased awearness related by "seeing the fluff", especially when it is for 1.16.3 which is considered "a dead dog", demands for 1.17 with "fliff" are "iceing on the cake", and people will get bug fixes to boot.. The idea "to leave fluff till last" is what keeps most "automotive projects in the garage for many years". Especially at this time, there is no longer this need, as there are immediate benefits to be had, some I have not even discussed yet, like "choose your own widget layout", which can be implemented in the same way as I have done with gradients, without impacting on code size or memory usage (or in this case, code functionality). Again, "two minutes" worth of work for some "flashy results", ones that will not impact on users that do not wish to partake.. a lot of this work in mundane, replicating c files, adjusting values, compiling instances then screen shotting them, "rinse and repeat" >> This XaAES v2 development should coincide with revisions of AES and >> VDI and related functions (like XBIOS if needed), eg. AES v5, >> revisions that can "last to the end of this millenium" as it were > > Having the VDI as a kernel module so the AES can call it directly will be a > huge benefit performance-wise. > > Jo Even I had not thought of this, fvdi.km, I am sure there would be (initially) a large amount of work involved, but as you will become aware, the best parts of fVDI are ASM, the parts in C have bee neglected simply because there was no one to pay them special attention. unfortunately for you and me, those part most neglected (or most rudimentary) are the same parts you an I would use on a regular basis. I feel envy for those currently using fVDI on mono setups, for the current use one of the fastest desktops in the world as a result, especially if they are not MiNT (they probably have to wear sun glasses to avoid getting blind by the shear speed of all those white pixels) > This is not meant as a rant, or as a finger pointing excersize, merely to point out that right now (and for at least the next 12 months) there is a serious need for good solid development in order to provide the new Atari Baby (Coldari) with the most fertile play ground possible, while fixing up all the toys that were left broken by its older brothers and sisters. This should not be restrictive an any way. None of the traditional "use and them" divisions, wheather it is ASM vs C, AES vs VDI, "this documentation" vs "that documentation", or demo vs non-demo (code and programmers), or any other parts.. it is a time to grab what we still have, tidy up the bit that need to be, apply "a fresh coat of paint" (while allow others to do the same), and get everything up to scratch, ready for the Basis of a new version of a "modern OS", that can seriously be described as "a Desktop Experience" while still allowing current hardware/platforms to benefit, before that boundary is crossed irreversibly. Jo, you your self can attest to the volume of suggestions I made concerning TaskBar and its possible uses, some of which would never have been raised even by other testers and users, which has resulted in your new version being even less compatible with the old version (INF), while adding functionality that may have a far reaching impact, as far as "a modern desktop environment" is concerned. I aim to keep the compatibility end of the equation "up" on current and historical setups, just a little while longer, before seeing a huge change the likes of which have not been seen since MiNT kernel was supplied for Falcons and TOS 4.04. A change that Amiga users had the chance to go through a few years ago, and BeOS users have just experienced. Apart from the current "need" to maintain 1.16.3 compatibility, my number one concerns are "speed", "size" and "editability", for you are right when you say (and other think) "when you loose interest or for other reasons have to drop this project", because it will happen, just not for the reason you or others can come up with. AND THAT is what AFROS-update is all about for me, I need to be able to "pick up run with" a dev environment and desktop, and continue to help out when I can, with out having to worry about "letting it go again" for what ever reason.. and that dev environment needs to be complimentary and compatible with current "future" platforms, while allow for "historical rewrites" and "back post" of what ever software may be needed, or just on a whim. I know there is a lot of history here, and there are a lot of "things" I have covered which may be neither simple nor to the liking of everyone, but if you wonder where I get the fire, go read some of the original kernel development threads like I did when I was 17 and sitting out in the wilderness at the bottom of the world where the idea of a new machine died when Atari folded, and the only one around to "fix" and "do stuff" for my Atari ST, was me. I aim to see that does not happen with anyones children or grand children, to the point that when the pick up "there chosen machine and OS" there first choice will be "an Atari ST or TOS compatible machine" because it will be that good... OK, better stop there... Sorry for the excessive inbox filler, but have a think about it, now is the time for ideas, and implementations, clean slates and what not.. Cheers Paul