Re: Adding asm examples

[Julio Merino <jmmv%NetBSD.org@localhost>]

On 11/15/11 10:42 PM, Valeriy E. Ushakov wrote:
> Julio Merino <jmmv%netbsd.org@localhost> wrote:
>> On 11/14/11 10:32 PM, Valeriy E. Ushakov wrote:
>>> Julio Merino<jmmv%netbsd.org@localhost>  wrote:
>>>> Exactly my point.  I could also RTFS of things people have pointed out,
>>>> but that's not my idea of "learner-friendly" material; specially for a
>>>> complete newbie in a topic.
>>>
>>> I understand your enthusiasm, but I still don't think teaching
>>> complete newbies assembly programming to be something that netbsd
>>> should consider a useful goal.
> 
> I still didn't get an answer to this question.  What does this all
> have to do with netbsd?

Unless I'm really mistaken, the way to perform syscalls and the way to
arrange the parameters to them is specific to the OS.  (In x86, IIRC,
Linux uses int 0x80 to invoke a syscall; do we use the same?  Do we
arrange registers in the same way?)

I'm not as sure about this, but: I also believe that the calling
conventions from C to ASM and viceversa are not universal and they
depend on the specific OS ABI, the platform and the compiler in use.

So if any of these assertions is slightly true, then, these examples are
NetBSD-specific.

>>> Especially so when the examples you
>>> choose are hardly "learner-friendly".
>>
>> As I have mentioned countless times already: the particular example I 
>> posted is poor, precisely due to my lack of knowledge on the area.  It 
>> can (and will, according to the suggestions already in the thread) be 
>> fixed to be more representative, so please stop looking at that example.
> 
> This is the only example that was committed and which is at least
> netbsd-specific.  What else was there to look at?  Ok, I will stop.

An attempt to clarify: nothing yet, because I have intentionally avoided
touching anything until we resolved this thread.  (The commits were
premature, driven by early supportive comments and my lack of time for
this stuff, so I didn't want to make the situation any worse by
committing more stuff during the discussion.  Maybe the actual
postponing of the changes is making things worse...)

> You also mentioned that
> 
> | There could be another example showing the C->ASM call protocol.
> 
> for which I suggested that there's nothing netbsd-specific about it
> and you can trivially obtain this kind of examples from the compiler.
> I think dsl@ also expressed his agreement with that last suggestion
> earlier in the thread.
> 
> Compile
> 
>     int foo(int a) { return a; }
> 
> with -S, rename the output to .S add it to your SRCS and hack away.
> Call foo() from your main.c.  Change signature of foo to suit your
> needs.
> 
> Have you actually tried that?

No (well, see below).  Why should I?  I know I could jump through hoops
to get to the information I need.  But this information belongs in
documentation, and documentation usually comes with supporting code, so
the intent of this is to provide the latter.

>> By the way, making fun of people does not seem like a good way to
>> convince them that they are wrong; it's just gonna piss them off.
> 
> It was never my intention to make fun of you.  The "look ma" comment,
> if that was what triggered your reaction, was about the original linux
> example that I vaguely remember seeing in passing some time ago.

Alright.  I'm just misreading text and overreacting; sorry about that.

>>> As I said, you are not helping any newbies, yourself included,
>>
>> Why do you keep assuming that this is useless, including to myself?  How 
>> can you decide what I can find or cannot find useful? 
> 
> Why do you keep assuming that your learning experience is
> representative of that of a typical subset of netbsd users?

Because other people, not only me, have expressed that they find this a
good idea.

> Have you tried "cc -S" route?  Did you find that it suck?  Confusing?
> Do you still want a hand-written example after trying cc -S?

I have been refusing to due to what I said above: it's not learning
material.

However, I just did try it and the output is "meh".  It includes some
things (not talking about the machine code itself, but about the .*
tags) that I can't explain right away.  Yes, I could now "info gcc",
look for the appropriate statements, etc. but that's the "jumping
through hoops" mentioned earlier...

Also, and because these output files will always rely on libc, they are
effectively not showing me anything about how they interact with the
kernel (which is what I was mostly curious about).

-- 
Julio Merino / @jmmv