Active Topics
-
Porting apps to Leste (29)
to Maemo 7 / Leste by Arno_11 - 2 days, 4 hrs ago -
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 3 days, 7 hrs ago - more...
|
2012-09-18
, 20:20
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#12
|
@teroyk,
Normally executable programs have a format. Linux uses ELF.
Normally executable programs have a format. Linux uses ELF.
|
|
2012-09-19
, 07:39
|
|
Posts: 477 |
Thanked: 611 times |
Joined on Feb 2012
|
#13
|
Originally Posted by reinob
thanks. And I found all Linux executable information:
@teroyk,
Normally executable programs have a format. Linux uses ELF.
http://www.kernel.org/doc/man-pages/...an5/elf.5.html
| The Following User Says Thank You to teroyk For This Useful Post: | ||
|
|
2012-09-19
, 07:54
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#14
|
Originally Posted by S0urcerr0r
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, ...)
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.
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.
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
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.
| The Following 3 Users Say Thank You to reinob For This Useful Post: | ||
|
|
2012-09-19
, 08:14
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#15
|
+1
I also stopped doing hand-optimized assembler code with 486. With one exception - stupid M$ compiler did't optimize well for Duron's pipelines, so I hand-optimized some mmx code (video decoder), but that was just an exception.
Using assembler makes absolutely no sense for general programming, especially now we have gcc 4.7.X. You may use assembler for some specific piece of code, but still, you won't beat compiler if you don't have a sh*tload of emulators, so you can trace pipelines, branches, caches, instruction dependencies, whatnot.
@Reinob - "smooth transitions" falls in the same category as "ecosystem" if you ask me
I also stopped doing hand-optimized assembler code with 486. With one exception - stupid M$ compiler did't optimize well for Duron's pipelines, so I hand-optimized some mmx code (video decoder), but that was just an exception.
Using assembler makes absolutely no sense for general programming, especially now we have gcc 4.7.X. You may use assembler for some specific piece of code, but still, you won't beat compiler if you don't have a sh*tload of emulators, so you can trace pipelines, branches, caches, instruction dependencies, whatnot.
@Reinob - "smooth transitions" falls in the same category as "ecosystem" if you ask me
__________________
Never fear. I is here.
720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900
Community SSU developer
kernel-power developer and maintainer
Never fear. I is here.
720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900
Community SSU developer
kernel-power developer and maintainer
| The Following User Says Thank You to freemangordon For This Useful Post: | ||
 |
|
2012-09-19
, 08:45
|
|
Posts: 46 |
Thanked: 131 times |
Joined on Jul 2011
@ Russia, Moscow area
|
#16
|
S0urcerr0r, take a look at asm source of my elf:
https://dl.dropbox.com/u/28532483/lo...mpress.v.1.1.s
And the same, but some updated at C:
https://dl.dropbox.com/u/28532483/lo...ress.v.1.2.cpp
Asm source can be compiled with:
I hope it will help you 
https://dl.dropbox.com/u/28532483/lo...mpress.v.1.1.s
And the same, but some updated at C:
https://dl.dropbox.com/u/28532483/lo...ress.v.1.2.cpp
Asm source can be compiled with:
Code:
gcc logo_compress.v.1.1.s -o logo_compress.elf
| The Following User Says Thank You to raandoom For This Useful Post: | ||
 |
|
2012-09-19
, 09:44
|
|
Posts: 640 |
Thanked: 435 times |
Joined on Oct 2011
@ rajvoSa BA
|
#17
|
ELF is actually ARMs executable and linkable file.
it's not just for linux, elfs can be loaded with symbian and with WinCE oses too.
FASMARM is one great assembler and it's opesource so it can be tweaked up too.
i think that writing includes for both maemo5 and maemo6 shouldn't be so hard.
i will try to do some contribution for harmattan at least
+1 for this thread
it's not just for linux, elfs can be loaded with symbian and with WinCE oses too.
FASMARM is one great assembler and it's opesource so it can be tweaked up too.
i think that writing includes for both maemo5 and maemo6 shouldn't be so hard.
i will try to do some contribution for harmattan at least
+1 for this thread
__________________
~ # mv /usr/bin/smartsearch /usr/bin/stupidsearch
| The Following User Says Thank You to wook_sf For This Useful Post: | ||
|
|
2012-09-19
, 10:33
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#18
|
@wook_sf,
ELF existed before ARM. It's used by most Linux/Unix operating systems, and is architecture-independent, meaning it can be used for x86, ARM, or whatever. Originally it was used for x86.
AFAIK Symbian used an ELF-like (or ELF-derived) format, but not quite ELF.
I'm not aware of any Windows (CE or not) versions using ELF natively. Windows (including CE) uses PE (portable executable).
ELF existed before ARM. It's used by most Linux/Unix operating systems, and is architecture-independent, meaning it can be used for x86, ARM, or whatever. Originally it was used for x86.
AFAIK Symbian used an ELF-like (or ELF-derived) format, but not quite ELF.
I'm not aware of any Windows (CE or not) versions using ELF natively. Windows (including CE) uses PE (portable executable).
|
|
2012-09-19
, 10:44
|
|
Posts: 640 |
Thanked: 435 times |
Joined on Oct 2011
@ rajvoSa BA
|
#19
|
Originally Posted by reinob
well, pe for winCE have ELF header same as PE for win32 have MZ (dos header)
@wook_sf,
ELF existed before ARM. It's used by most Linux/Unix operating systems, and is architecture-independent, meaning it can be used for x86, ARM, or whatever. Originally it was used for x86.
AFAIK Symbian used an ELF-like (or ELF-derived) format, but not quite ELF.
I'm not aware of any Windows (CE or not) versions using ELF natively. Windows (including CE) uses PE (portable executable).
ELF is officially supported by arm and that format is used for this processor.
there was one really really good book about arm asm that explains lot about assembly, in my opinion far better for students than any other book i've read
and i will try to link it here.about symbian - i wasn't talking about EPOC, but about ELF
basicly, elfs should be runnable on every arm machine
__________________
~ # mv /usr/bin/smartsearch /usr/bin/stupidsearch
|
|
2012-09-19
, 11:17
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#20
|
@wook_sf,
OK, this is getting off-topic, but:
PE does not and cannot have an ELF header. PE is a different format than ELF.
An ARM processor can run ARM instructions. The format of the executable file is of no concern for the processor, but for the operating system (dynamic linker), which needs to be able to identify the code sections so that they can be executed by the processor.
Symbian uses the E32Image format. During compilation with the standard tools a PE or ELF executable is generated. This executable must be then converted to E32Image so that Symbian can use it.
(see http://www.antonypranata.com/node/9).
As for "ELFs should be runnable on every arm machine". The statement is obviously true, as long as the operating system can make sense of (use the) ELF format.
That's like saying "ZIPs should be extractable on every ARM machine". Yes, but you need the unzip tool for that machine. Same as x86, mips or any other CPU architecture.
Now we can go back on-topic
.. unless, that is, you have some references supporting your assertions..
OK, this is getting off-topic, but:
PE does not and cannot have an ELF header. PE is a different format than ELF.
An ARM processor can run ARM instructions. The format of the executable file is of no concern for the processor, but for the operating system (dynamic linker), which needs to be able to identify the code sections so that they can be executed by the processor.
Symbian uses the E32Image format. During compilation with the standard tools a PE or ELF executable is generated. This executable must be then converted to E32Image so that Symbian can use it.
(see http://www.antonypranata.com/node/9).
As for "ELFs should be runnable on every arm machine". The statement is obviously true, as long as the operating system can make sense of (use the) ELF format.
That's like saying "ZIPs should be extractable on every ARM machine". Yes, but you need the unzip tool for that machine. Same as x86, mips or any other CPU architecture.
Now we can go back on-topic
.. unless, that is, you have some references supporting your assertions..
| The Following User Says Thank You to reinob For This Useful Post: | ||
- Just install Binutils in N900
- Open texteditor (I use nano) and write code
- Assemble with as-command
- Link with ld-command
- set execute rights with chmod
- run (remember put ./ before your program name)
But I have question why
mov r7,#4
looks with hexeditor like this:
hex 0407A0E3=bin 0000 0100 0000 0111 1010 0000 1110 0001
but If I look ARM instructions manual, it should look like
1111 0i10 0100 imm4 0imm3 Rd imm8
or
1111 0i00 010s 1111 0imm3 Rd imm8?
And why there is in executable file 74 bytes before first command come? And lot bytes after commands and data?