Initial post

[jeff]

Old age is creeping up and I've got a collection of assembler programs
written in the last 30 years. Had hoped to put them all on sourceforge,
but can't get into my account anymore. Think "Google code hosting" is a
better option. Anyway, the plan is to put everything on "Google code"
and use this group to collect any questions or comments. A yahoo group
also exists, but it is mostly spam and inferior to most things google.
I've made the group public. Doubt that will be a problem, we will see.
It would be interesting to hear from anyone working in assembler.
Suspect I'm the only one writing applications.
Jeff

[Fabio D'Alfonso]

Hi,
I was astonished in seeing your incredible work in assembly and nasm, with asmtools, and what it represents in terms of "what is possible to do" .

I was directed here by Frank Kotler, that also asked me to send his greetings and invite you to join the nasm website. I would really learn to flat the knowledge about assembly/nasm (meaning when it becomes only a matter of time and patience, not of being able to) and never found something good as you bright work to show that I mean.
I am not interested to just tutorials, what I found sad about assembly is that almost anything is a sample, seeing your work hits the critical mass and gives a proof to follow.

Hope to listen to you, meanwhile THANKS

Fabio D'Alfonso

[jeff owens]

Hi Fabio,
It was nice seeing your email to linuxasm. I think there are three people on list and not much interest in linux assembler. I spent years writing programs and use them each day. It makes me happy to think someone else might use one of the programs. If there is anything you want talk about, it would be good to see some emails here. I have lots of time to write.
all the best, Jeff Owens

[Fabio D'Alfonso]

Hi,
I am really interested in going fluent with assembly, not only play. Your great work is a great motivator, I started about some two months ago and plan to go on next months. I started using the Duntemann book, as many others. Really good to win the start but with a short hand.

Now I am using a book from Cavanaugh where there is large discussion on floating point, BCD, and other topics and a large description of the instruction set . This is part of my interest on compilers and I would end with a Pascal Compiler written in mixed/floating C++/C/NASM. Compilers are one of the most discussed topics in literature with some peculiar extensive hands on stuff side by side with theoretical books.

Abstracting is different from hiding, in that one should know what is that being abstracted... or you better think of hiding.

I just started to 'look for' what could do this and that in the instruction set, e.g. got the idea to use repe cmpsb to look for a part of a string as HOME in environment variables on the stack.

My current understanding is that is relevant to fight the fear and being able to stay curious to assemble brick by brick what I will need, and time by time the process will eventually short in time and 'stress'. In this, being able to ask something to a person who already got it at the best is a great  support, in itself.

Thanks

[Fabio D'Alfonso]

Hi,
what I forgot to say is that all along with the larger project I described there a smaller one , to be made in solely nasm, a nasm code formatter, that belongs to the same family, sharing some compilers knowledge to be able to format the code.

Thanks

Fabio D'Alfonso

--
You received this message because you are subscribed to the Google Groups "linuxasm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxasm+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/linuxasm.
For more options, visit https://groups.google.com/d/optout.

--
Fabio D'Alfonso
cell. 348.059.40.22
email: fabio.d...@gmail.com

[jeff]

Good Morning Fabio,
I like your brick by brick approach to assembly. It can be fun if you
limit the scope. My approach was to identify the instructions common to
all x86 processors and focus on them. This makes writing assembler
simpler. The resulting programs are very efficient and somewhat
portable. Moving assembly between X86 processor modes and ARM processors
is easy for me. Most people think all assembly work is difficult and
tedious. I'm confused by these claims.

Searching with assembler can be interesting. Have you looked at fast
search algorithms? I think one is called "Boyer" and works on big data
files. Sometimes it is faster to use "CMP" and "LOOP" rather than "repe
cmpsb". It depends on how the search loop works. Different processors
give different results. Today everyone depends on compilers to handle
most of these low level details, but to get amazing results, assembler
is best.

I think compiler writing and application programs are very different
worlds. You are very ambitious to attempt both. I assume your compiler
world would be focused on generating assembler. The actual compiler
would be written in another language. The compiler generated assembler
would be targeted to a processor family (80386, pentium+, ARM, others).
That is a world I stay out of. They change the processors every few
years and it gets confusing.

There is a rediciolous statement by a famous American (Henry Ford). He
said: "if you believe it can't be done, it cant. If you believe it can
be done, it can" The statement is both nonsense and true. Anyway, I've
found it fits assembler projects. What do you plan to attempt first?

all the best, Jeff

[Fabio D'Alfonso]

Hi Jeff,

thanks a lot for sharing your considerations.

Hopefully you will not find too elementary some of my considerations.

Just now I am rechecking my knowledge and making links to sideways to clarify in any possible way some things. I suffer the fortune of not liking intuition as a substitute of comprehension and sometime can be a bit cumbersome, but that is something working good , if got to the end.

e.g. I was just now make this simple coding:

 section .data ; Section containing initialized data
 
 section .text ; Section containing code
 
 global _start ; Linker needs this to find the entry point
 
 _start:
         nop   ; This no-op keeps gdb happy
 here:
         mov eax,3
         mov ebx,2
         cmp eax,ebx
         jg here
 
         nop

because, despite the long explaining stuff of cmp  op1,op2 being op1 - op2  nothing told what is op1  or op2   to be greater of the other. It seems to me that nothing in itself says that is the eax > ebx to jump.

I am trying to give a try to everything I cannot give clear outcome and taking notes.

Also I am trying to collect info about the most used sys_calls needed to interact with the world. Unfortunately the < > mode makes examples simple but also a problem to find the most elementary  ways to interact with files from assembly.

I made some research to use 90 91 mmap unmap and got some clue to use structs for long list of parameters  and mapping to the kernel defined counterpart.

I already made a small skeleton in which I got a command line argument file, mmap, make some fictional change, and unmap to disk, putting together what I got. Now I getting bank inside the assembly to think how to make text formatting step, that will need to check for a config file to open (getting info from the stack about HOME).

So the first thing I would get is this asmstyle  text formatter.
 

The compiler would be written in C++/assembly but the real goal is the mixing of assembly/C/C++ in a floating fashion, using .o .a asm libraries called by HLL using C calling conventions.

About the assembly, my main point is becoming fluent to make it just a matter of time and patience, so now I am doing something specific to win confidence that I will be later able to use it to solve other problems.

As with assembly the journey is the goal I think that committing a fixed time, let's say every day, to stay on the line, is the first milestone in the travel. So I did.

Thanks a lot

Fabio  

 

--
You received this message because you are subscribed to the Google Groups "linuxasm" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linuxasm+unsubscribe@googlegroups.com.

Visit this group at http://groups.google.com/group/linuxasm.
For more options, visit https://groups.google.com/d/optout.