Page 2 of 3 1 2 3
Reply
Thread Tools
teroyk is offline teroyk
2012-09-18 , 14:48
Posts: 518 | Thanked: 635 times | Joined on Feb 2012
#11
It is very easy.
- 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?
 
reinob is offline reinob
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.
 
teroyk is offline teroyk
2012-09-19 , 07:39
Posts: 518 | Thanked: 635 times | Joined on Feb 2012
#13
Originally Posted by reinob View Post
@teroyk,

Normally executable programs have a format. Linux uses ELF.
thanks. And I found all Linux executable information:
http://www.kernel.org/doc/man-pages/...an5/elf.5.html
 

The Following User Says Thank You to teroyk For This Useful Post:
reinob is offline reinob
2012-09-19 , 07:54
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:
freemangordon is offline freemangordon
2012-09-19 , 08:14
Posts: 3,074 | Thanked: 12,964 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
__________________
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:
raandoom's Avatar
raandoom is offline raandoom
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:
Code:
gcc logo_compress.v.1.1.s -o logo_compress.elf
I hope it will help you
 

The Following User Says Thank You to raandoom For This Useful Post:
wook_sf's Avatar
wook_sf is offline wook_sf
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
__________________
~ # mv /usr/bin/smartsearch /usr/bin/stupidsearch
 

The Following User Says Thank You to wook_sf For This Useful Post:
reinob is offline reinob
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).
 
wook_sf's Avatar
wook_sf is offline wook_sf
2012-09-19 , 10:44
Posts: 640 | Thanked: 435 times | Joined on Oct 2011 @ rajvoSa BA
#19
Originally Posted by reinob View Post
@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).
well, pe for winCE have ELF header same as PE for win32 have MZ (dos header)
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
 
reinob is offline reinob
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..
 

The Following User Says Thank You to reinob For This Useful Post:
Reply
Page 2 of 3 1 2 3

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 16:49.

Contact Us - Home - Archive - Top