I'm desperately trying to open a window
under KDE in Assembly language. On the Internet
I found nothing about. Did anyone succed ?
Thanks
Joseph
http://www.informatik.uni-ulm.de/pm/mitarbeiter/mark/write_in_c.html
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
or mailto:mcxumhv...@skrammel.yaboo.dk
> Giuseppe Torelli wrote:
>>
>> Hi,
>>
>> I'm desperately trying to open a window
>> under KDE in Assembly language. On the Internet
>> I found nothing about.
>
> http://www.informatik.uni-ulm.de/pm/mitarbeiter/mark/write_in_c.html
>
I asked help, not a silly answer, I prefer to code in Assembly because
C is translated in Assembly when compiling, the code is bigger than the
assembly one, C++ syntax is a great mess:
http://linuxassembly.org/howto/landa.html
Regards,
Joseph
> Kasper Dupont wrote:
>
>> Giuseppe Torelli wrote:
>>>
>>> Hi,
>>>
>>> I'm desperately trying to open a window
>>> under KDE in Assembly language. On the Internet
>>> I found nothing about.
>>
>
> I asked help, not a silly answer, I prefer to code in Assembly because
> C is translated in Assembly when compiling, the code is bigger than the
> assembly one, C++ syntax is a great mess:
>
> http://linuxassembly.org/howto/landa.html
>
> Regards,
> Joseph
Giuseppe, why do you need to use assembly? Are you trying to shrink the
size of your program? Get more speed? Are you writing for an embedded
system? Do you need to write your whole program in assembly?
I'm thinking that interfacing with shared libraries in assembly would be a
chore. Maybe you could mix assembly with C or even C++ to interface with
the windowing system. But if you're trying to save space maybe KDE is not
the windowing system for you!
--
Luca Pireddu
Mirarco - Laurentian University
Email: lpir...@n.o.s.p.am.mirarco.org
But that was a very serious advice. I really consider writing KDE
applications in KDE to be silly. And if you really want assembly
code, then just write the code in C and let gcc translate it to
assembly code.
I don't believe you can give me a single good reason to write a
KDE application in assembly.
and see how the assmebly looks like.
This is a matter of opinion. I don't consider so.
And if you really want assembly
> code, then just write the code in C and let gcc translate it to
> assembly code.
Have you ever tried to do so ? It is evident you didn't, otherwise you would
not have written such a statement. The assembly code produced by gcc is
long and understandable.
> I don't believe you can give me a single good reason to write a
> KDE application in assembly.
Yeah, I don't have to give any justification to what I decide to do.
The produced assembly will look like a great mess Nils, as you probably
don't know. Anyway I asked help but I received only personal opinions and
very stupid commonplaces.
My deep apologies for posting in a newsgroup where C programming is the
god...
An academic exercise, perhaps?
I suggest writing in C, translate to assembly using gcc
and then reading the assembly to find out how it is done.
> The produced assembly will look like a great mess Nils, as you probably
> don't know. Anyway I asked help but I received only personal opinions and
> very stupid commonplaces.
See the (rather long) discussion we had about assebly programming on
c.o.l.d.s a while back.
> My deep apologies for posting in a newsgroup where C programming is the
> god...
--
Måns Rullgård
m...@users.sf.net
> The produced assembly will look like a great mess Nils, as you probably
> don't know. Anyway I asked help but I received only personal opinions and
> very stupid commonplaces.
Well, it's not a bad suggestion. What do you want? Someone to code
the assembly for you and show it to you? This would be a good starting
point for you, and if you can't understand gcc's assembly, maybe you
shouldn't be trying to program GUIs in assembly.
--
Joshua Jones
josh(at)homemail.com | jonesjos(at)us.ibm.com
cat >xtest.s <<eof
.data
.section .rodata
displayname:
.string ":0"
ptemplate:
.string "Display: %d\nDefaultWindow: %d\nWindow:
%d\n"
.text
.align 16
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
pushl $displayname
call XOpenDisplay
movl %eax, -4(%ebp)
call XDefaultRootWindow
pushl %eax
pushl $0
pushl $0
pushl $4
pushl $200
pushl $200
pushl $100
pushl $100
pushl -8(%ebp)
pushl -4(%ebp)
call XCreateSimpleWindow
addl $36, %esp
pushl %eax
pushl -12(%ebp)
pushl -4(%ebp)
call XMapWindow
pushl -12(%ebp)
pushl -8(%ebp)
pushl -4(%ebp)
pushl $ptemplate
call printf
addl $16, %esp
pushl -4(%ebp)
call XFlush
pushl $10
call sleep
movl %ebp, %esp
popl %ebp
ret
eof
gcc -o xtest xtest.s -lX11 -L/usr/X11R6/lib
The above opens an XWindow using low level Xlib calls, waits 10s then
exits. For a real application you probably want to use a widget toolkit
such as Motif.
I strongly recommend you do not use assembly for this kind of thing. If
you require the absolute best possible performance write assembly to
handle the performance critical stuff but write the bulk of your code in
C or C++. If you attempt to write everything in assembly your project
will take a very long time to complete. Most of the time the GNU C
compiler generates good assembly, I have to be pretty desperate for
performance to write assembly by hand.
Eric Worrall
--
You have just received an Etech Solution
For all your Linux requirements contact
ewor...@netcomuk.co.uk
My, oh my, that's an argument in favor of using MakeAShorterLink...
<http://makeashorterlink.com/?X2DA12F91>
And it's just not terribly sensible to try to program stuff like KDE
in Assembler.
If all you want to do is to open a single window, with something in
it, writing in straight assembler would be a way to get the binary
smaller than you ever imagined it would be.
But once it turns into a full-scale KDE application, you start getting
into:
-> Marshalling arguments into KDE/Qt data structures, and
-> Calling great gobs of code written in C++
And the gains quickly evaporate.
If someone is really into writing assembler code, there are some
meaningful projects to look at:
a) Consider writing some libraries in assembler to improve
performance.
The Alpha folk did this with the trig and transcendental
functions, as rewriting those in assembler provided a considerable
speed boost over what got automagically generated by GCC.
b) Add some assembler patches to XFree86 to improve its performance.
Building apps totally in assembler just isn't going to be as
satisfactory.
One of the reasons that the FSF/GNU Project got started was that they
got really seriously _screwed_ over code written in assembler. There
was lots of code that the MIT AI lab had written as 'free software'
back before Richard Stallman tried to take over "mindshare" for the
term that suddenly became useless when Digital decided the future was
in the VAX and that the PDP-* series was to be discontinued.
ITS was written in assembler, and suddenly became unsupportable.
We can see the same "trainwreck" coming as Intel has been trying to at
least feign the notion of making IA-32 obsolete.
"64-bit integers aren't silly. For instance Bill Gates, of
Microsoft fame, is now worth more than $4 billion. You can't
represent his net worth in 32 bits in dollars, let alone cents." --
Charlie Price
32 bits are becoming increasingly constraining, and software written
in IA-32 assembler is liable to be pretty useless if and when a 64 bit
alternative becomes a decent migration path. (And no, SPARC and Alpha
and Itanic aren't that, at this point.)
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://cbbrowne.com/info/oses.html
0 7 * * * echo "...Linux is just a fad" | mail bi...@microsoft.com \
-s "And remember..."
> I'm desperately trying to open a window
> under KDE in Assembly language.
Just call the same library routines you would in C/C++.
How to do that (parameter passing, etc.) depends on which
architecture you're using.
--
Grant Edwards grante Yow! Yow! Am I having
at fun yet?
visi.com
What you got was very sound advice. While your own code may be
marginally smaller than the code generated by gcc, but the time you've
linked in all the libraries you need the size of your little toy
program isn't going to matter.
If you insist on proceeding, write a 15-line C++ program that uses Qt
to open a window (that's what you really meant when you said a KDE
window, right?), read the generated code, and imitate it. Yes, I saw
above where Nils gave you essentially the same recommendation and you
responded that GCC code is a ``great mess;'' that's the only way
you're going to get the answer, however.
This isn't a newsgroup where C is god, it is however one for Linux --
not just on IA-32, but on all supported architectures. Asking how to
do something that is inherently non-portable is a quick route to being
told not to do that. Deciding you want to write a project in
assembly, unless you've got some really special constraints or you
just want to learn the language, pretty much demonstrates you don't
know what you're talking about.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Should of course have been: "I really consider writing KDE
applications in assembly to be silly."
I have tried doing this with small programs. With large programs of
course it is going to produce a lot of code. But if you are looking
for an easy solution, assembly is not the way to go.
>
> > I don't believe you can give me a single good reason to write a
> > KDE application in assembly.
>
> Yeah, I don't have to give any justification to what I decide to do.
Without knowing what you are trying to accomplish I cannot give you
any better advice than I have already done.
Exactly my point.
And noone has to answer what you ask, either.
If you want an answer, I can tell you this much: it's gonna be really
really really hard to do.
For one thing, all the code needed to create a "KDE window" is on
libraries, so you need to link them into your binary.
Those libraries are only available as dynamic modules, so this is
going to be more difficult.
Those libraries are written in C++, so you gonna have to find the
jump point for the mangled functions, and create C++ objects in
assembler. You may make this a bit easier, if using QtC you can
use C functions instead, but not all that easier.
Finally, creating a KDE window in assembler sounds pretty silly.
If you expect people to help you in what seems like a silly endeavour,
you have to explain why it is not silly, or you get answers like
"that is silly".
And yes, so far, it seems it is just silly.
--
Roberto Alsina
I very well know that. The problem is that noone does KDE programming in
assembly, so this might be some of the best you can get.
Or try finding some documents on how to interface C++ from assembly in general
(if such things exists)
> >> Nevertheless, just write a very small example in C/C++ and
> >> do
> >> gcc -fverbose-asm -S -o out.s -c out.cc
> >>
> >> and see how the assmebly looks like.
> >
> > The produced assembly will look like a great mess Nils, as you probably
> > don't know.
>
> I very well know that. The problem is that noone does KDE
> programming in assembly, so this might be some of the best you can
> get.
Since x86 assembly is inherently a mess due to the entire architecture
being a mess, a mess is all you will ever get.
--
Måns Rullgård
m...@users.sf.net