[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
--------------------------------------------------
From: "Paul Wratt" <paul.wratt@gmail.com>
Sent: Wednesday, December 09, 2009 1:08 PM
To: "mint" <mint@lists.fishpool.fi>
Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
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
1. There is no such thing as bug free code.
2. When they become outdated, the work must be done all over again.
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.
So you are saying that it's hard to implement good algorithms in C, but
easier in assembler? That doesn't make any sense to me. Not only do you have
to implement a good algorithm, you also have to beat the C-compiler when
optimizing the code. No matter how you put it - assembler means a lot more
source code than C to do the same thing, which means harder to read code and
lots more possibilities for bugs.
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).
Sorry, but I don't understand what you mean here. Are you saying that since
a C compiler compiles code to machine language, you might as well use
machine language in the first place? Why not just do it all in hex? With
dip-switches?
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..
Sorry, but I don't understand what you're saying here.
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
This is all VDI-stuff! All of this is done by the device driver. It has
absolutely nothing to do with the AES.
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
Don't mix demos into this. They are not meant to be maintained. You can
write demos in hex for all I care, as I'm not using them and I don't need
bugs fixed. I do use MiNT/XaAES though, and I'd like to see it become more
easily maintained. Asm is definitely not the way to go.
Having the VDI as a kernel module so the AES can call it directly will be
a
huge benefit performance-wise.
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
I don't know much about the internals of fVDI, but then I didn't mention
fVDI at all. It might not even be suitable for integration with the kernel.
Ozk made a VDI a few years ago, but unfortunately he never released it
before he left the Atari scene. I know that he was thinking about a
VDI-kernel module too.
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.
Yes, there is always need for development. But you also have to look ahead.
How would the situation have been today if Ozk hadn't switched from
assembler to C when he started working on the XaAES kernel module? How many
people could have picked up his work if it was all assembler? Or what if the
kernel was 100% assembler? First of all, it would require a huge amount of
work to get it working on Coldfire in the first place. Secondly, very few
would be motivated or knowledgeable enough to do it.
(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
The BASIS is the design, the datastructures and the algorithms. It could be
implemented in assembler or C, but no language can fix a broken design.
Take the current pixel detection issue. Why does XaAES care about pixel
layout? If it needs to build bitmaps itself, it should build them in the
standard VDI format, and let the VDI convert it to a device dependent
format. Then this would never had been a problem at all! "Fixing" this by
adding other (perhaps faster) bitmap manipulation routines is... well... not
fixing. If the problem is in the VDI, then fix the VDI.
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 really don't see the relevance here. I'm rewriting Taskbar to reduce code
size and remove old, badly implemented stuff. I'm not rewriting it in
assembler ;-)
Taskbar consists of around 200Kb of C source. When disassembled, there's
almost 500Kb of uncommented assembler source. Which one would you think is
hardest to maintain? Which do you think has most bugs? Which one would YOU
rather maintain when I can't/won't anymore?
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
Which pretty much excludes assembler. "Future platform" might be a
completely different CPU.
Jo Even
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4672 (20091209) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com