Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Paul Wratt <paul.wratt@gmail.com>]

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 <joska@online.no> wrote:
> --------------------------------------------------
> From: "Paul Wratt" <paul.wratt@gmail.com>
> Sent: Wednesday, December 09, 2009 8:33 AM
> To: "mint" <mint@lists.fishpool.fi>
> 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