View Single Post
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#14
Originally Posted by S0urcerr0r View Post
1. Speed - i rather sacrifice compatibility in exchange for speed when coding for the N900 - why i needed to know if the OS makes some restrictions thats good to be aware of.
The idea is in itself good. The problem is that the CPU on your N900 is no Z80, no 8080 and no 80286. Meaning you have a f*ckload of "features" (predictive branching, out of order execution, etc. etc. no to speak about the different instruction sets that you can use in parallel: neon, thumb, thumb2, vfp3, ...)

So there's no way a human could possibly beat a good compiler (and we have good compilers) in optimizing code.

I also used to hand-optimize my programs (mostly 286 and 486). I stopped with the first Pentium.

2. Reverse Engineering - if i get much more experienced, i want to take a look at the PowerVR driver (and some other drivers) to see if theres a reason that VSync dont work as it should on the N900. by comparing the N900 SGX driver to other phones SGX driver with the same chipset (Palm Pre, Motorola Droid, Iphone 3GS, etc) there may be some way to hack the driver to get better a better framebuffer in RAM, and activating VSync ...for that i will need alot of experience and find the Code that handles transfers to the framebuffer - and somehow force vsync, instead of realtime rendering.
Good luck. I don't see why VSync is necessary. But again, I don't see why one of the most important features of a modern smartphone has to be the "smooth" transitions. It's just a damned phone/computer. You use it (work with it), and then you lock the screen or turn it off. There's no point (IMHO) in just staring at your N900 while you swipe left and right. It's enough that most so-called "hands-on" tests on the Internet do exactly just that. I find it painful/shameful to watch. Anyway..

also reverse-engineering can be good to optimize the most hogging parts of the kernel and system background tasks.

EDIT: PS. with reverse engineering i will probably need a disassembler to be able to understand the machine code, but i guess such already exists
As noted already in this thread, the kernel is open source. It's generally (but not always) preferable to review/patch source code compared to reviewing/patching executable code. There are notable exceptions (for some time I always applied a binary patch to all my kernels, as well as to pine. But that's off-topic here).

Most (all?) services and daemons running in your N900 are also open-source.

but i need to get started somewhere and i know its a far way to go if i want to get that good... i remember the author of ZSNES (fastest snes emu for x86) developed it as a asm project (and some c and c++) while learning assembler at the university.
You can do lots of things in assembler, but think of it as a language and you'll feel more comfortable with it. Otherwise you'll assume that using assembler you have direct access to hardware (which is wrong) and that your code will run faster (which is also wrong).
 

The Following 3 Users Say Thank You to reinob For This Useful Post: