Re: A more structured approach

Hello Frank,

Hmmm... I don't see what that's going to do. To get a "full path", you'd
want to concatenate the two strings. To tell if you were called as the
real file, or a link, you may not care what the full path is - "it
depends", I guess.

Yes sorry, I've been looking at doing this the most difficult way

pwd: .ascii "PWD"

I'm not familiar with Gas syntax. Do you want ".ascii" or ".asciz"?
Maybe the same thing, but it sounds as if one is zero-terminated and the
other not(?). You want this to be zero-terminated. If there's nothing
after it, it will probably be followed by zero padding, so it'll still
work, but if you put anything after it, it'll break.

I thought not in this case, cause I just wanted to test whether "PWD=",
there is
a "=" short, were the same as the begining of the data the register
points to

Well, it won't make any difference in this case, I don't think, but
"scas*" is slow, compared to individual instructions. For this *one*
purpose, a simple dword cmp with 'PWD=' would do.

I couldn't do it any of the ways. I'm finding gas a bit strict, and
quite raw
and difficult to get to know.

I've been trying the other way round, which is, I get the begining of
the first environment variable, and then start looking in reverse
order till I find the first "/", then I'd have binary name, as well
as current working directory, all in one go.

I've tried all the possible ways one could imagine. Pure heuristic,
none of them
worked, from cmp*, comps*, using rep, using test, etc, etc.
Surprissingly, I get
some decent result with sub. I've uploaded the source:

http://es.geocities.com/ucho_trabajo/asm/test.s.txt

For a more general
"find an environment variable" routine - which would be more useful -
you'd want a general "string compare" routine. "cmps*" might be more
appropriate than "scas*" - I think that even a naive "instruction by
instruction" routine will be plenty "fast enough" - we only have a small
amount of data - and may well beat "cmps*". My understanding is that
"rep movsb" has been kept optimized, but that the other "string"
instructions have gotten slow, compared to equivalent discrete
instructions. For the purpose of a "string compare" routine that'll be
fast on large data sets, you might care. For the purpose of learning
some assembly language, you don't. Anything that works will be fine.

Basically I'd like anyone to tell me somethig about the approach used,
so I can have feedback o how I'm understanding assembler.

One thing that comes to mind, is that you've set %ebp equal to initial
%esp, but not used it. Does no harm. Saving the initial %esp is a good
idea... I'm not sure %ebp is the best place...

Well, I'm taking this from the programming grund up book, where do you
sugest to save it then?

Since I'm testing so many things one after another, and I don't use to
delete code that doesn't break, although I should have done it before
pasting it, my fault.


I'm not good at "structure". Probably a result of not learning a
"structured" language before asm. What C does (I think), is to push what
you're calling "start_vars", then push "start_args" (the address where
the command-line args start), then push the argument count, then call
"main". I think what I'd do is to save initial %esp someplace "global".
But I would then pass that as a parameter to my "find environment
variable" routine. The environment for this program "is where it is",
but it's possible to spawn a child process with a "fake" environment,
and we might want to be able to search that, too.

That's about all I can think of. Seems to me you "get the idea" alright.


Thanks, well I couldn't do that kind of things before the next couple
of moths I reckon.

Kind Regards,

.

Relevant Pages