You got it darn good! I'm impressed. Somebody's been paying attention!
I see that you're realizing how the .data storage locations are arranged and
can be accessed from the way you got write to write the 3 bytes beginning at
item1. Great thinking!
Did you think of a block of bytes?
  item .byte 0,0,0,0

That would be an array of bytes.  Then you could access them through indicing.

And that is a good segway into leal... You asked:

  leal item1, %ecx  #still not knowing what is this really

The opcode 'lea' stands for "leave effective address". (the suffix 'l' means 'long' (32 bits))
So it "leaves the effective address" in %ecx as the location for 'write' to
find the begining of the bytes to write to stdout (which is the 1 in %ebx).
leal may be a bit overkill because the same thing can be accomplished with:
  movl $item1, %ecx  

But how about a demo to show what leal is able to do:

So I noted the results of different things I tried.  
So you can see that "effective address" means address after specified calculations. And here is some gdb output:
18        leal item(,%edx, 1), %ecx
2: /x $ecx = 0x0

(gdb)
_start () at zat-21.s:20
20        int $0x80
2: /x $ecx = 0x80490a0

(gdb) i address item
Symbol "item" is at 0x804909c in a file compiled without debugging.

(gdb) x /8xb 0x804909c
0x804909c <item>:      0x61    0x62    0x63    0x64    0x65  0x66  0x67  0x68
         
 For counting-->  0x804909c      9d      9e      9f      a0    a1    a2    a3

And the printed chars?:
(gdb) s
efgh_start () at zat-21.s:23      <-- see them at the beginning?
23        movl $0x00000001,%eax
2: /x $ecx = 0x80490a0

Ok so you've run the code in gdb up to the  STOP 1 using the same gdb display 
lines as I showed in the code above, right?   That means we have done these instructions:

  movl %esp , %ebp   #Get beginning stack location (presently in esp) into ebp.
  pushl $0x11        #Note that esp value (an address) is decremented with each
  pushl $0x2233      #push while ebp's value stays the same
  popl  %eax         #gets the last pushed value into eax

So there, we have pushed two values 'onto the stack'.
So what the heck is the stack???

It's an area of memory in which our process can place and retrieve values.
It's stored in a different area than the .bss or .data and .text sections are.
It is called 'the stack' because we primarily push and pop 4 byte words to and
from it... so a stack of words, you push one onto the stack, and pop one off.

Now, "push X onto the stack' is a tricky expression to use because it implies
that the new value is stored at a higher address we will see that succesive
values are placed at a lower addresses.  So,, the stack is upside down.

We are actually pushing values to the bottom of the stack....
This is an important thing to understand because in practical use of the
stack we will NOT be using variable names , ,  we will be refering to
values at addresses according to their relativity to a known address.

Like if I know the value of the base address, then I can subtract 4 bytes from
that which would give me tha address of where the first push stored a value.

Now for the obligatory illustration of four 4-byte 'words' on the stack:

base item:  base address  0xbfd4eff0   <--ESP start with this value
 1st item:     base -  4  0xbfd4efec      Note 4 byte difference
 2nd item:     base -  8  0xbfd4efe8      in address values
 3rd item:     base - 12  0xbfd4efe4      (also , your address values WILL be different)

There are registers especially for use with 'the stack':
ESP - Stack Pointer -holds address of last location that was pushed to
EBP - Base  Pointer -used to hold the address of a reference point or 'base'
ESI - Stack Index   -utility, to hold address to be accessed or an indice value

We can use these registers in many ways to manipulate the stack data.
But enough chat for now, lets see if I can demonstrate some things.
In gdb with display set up as I show at the bottom of the code section above,
I do first 3 instructions:
( Please play along on your own computer to really get a good feel )

(gdb) run
Starting program: /asm/myex/zat-24
Breakpoint 1, _start () at zat-24.s:11
11        movl %esp , %ebp   #Get beginning stack location into ebp.
4: /x $eax = 0x0
2: /x $esp = 0xbfd4eff0
1: /x $ebp = 0x0

(gdb) step
_start () at zat-24.s:12
12        pushl $0x11        #Note that esp value is decremented with each
4: /x $eax = 0x0
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4eff0
1: /x $ebp = 0xbfd4eff0

(gdb)
_start () at zat-24.s:13
13        pushl $0x2233      #push while ebp's value stays the same
4: /x $eax = 0x0
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efec
1: /x $ebp = 0xbfd4eff0

(gdb) s
_start () at zat-24.s:16
16        popl  %eax         <--- stop when you see this line queued...
4: /x $eax = 0x0
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efe8
1: /x $ebp = 0xbfd4eff0

Remember the instruction you see queued up will be executed at the next step.
All the values you see are after the previous step.

You can see that EBP starts out with a 0 , (hey it's a 'NULL' pointer)...
... and ESP starts out with an address loaded.  An interesting address at that.
At that address is the value we in C and C++ know as 'argc'!   (more on this below)
So at the first instruction, I move that address into ebp so that ebp will hold
that 'base address' making it available to use later as a stack reference point
or 'base pointer' as the value in esp will soon change with this first push:
  pushl $0x11

So what about this 'push' thing.  Well, after the first push notice that
esp's value has decremented by 4.
  from: $esp = 0xbfd4eff0    to: $esp = 0xbfd4efec

In hex: f0 - 4 = ec   [ f0 , ef , ee , ed , ec ] see?  (if not study hex NOW)

So a PUSH :
- subtracts 4 from the address held in esp and
- 'writes' the specified  'word' (4 bytes)  of data to that new address.

And now the next push:
  pushl $0x2233

So after two pushes esp holds the address where the last pushed value is stored.
Now lets take a look at the values we have on the stack:
(gdb) x /xw $ebp
0xbfd4eff0:     0x00000001

(gdb) x /xw $ebp - 4          <--- Note the specification: address - 4 bytes
0xbfd4efec:     0x00000011

(gdb) x /xw $ebp - 8          <--- Note the specification: address - 8 bytes
0xbfd4efe8:     0x00002233

Now, esp should be pointing to that same location.  Does it? Of course it does:
(gdb) x /xw $esp
0xbfd4efe8:     0x00002233

Now above you see the value stored at ebp and say "what's with the 0x00000001 ?
That's the argc value!  Meaning that there is 1 command line argument.
That argument is the actual command path used to start the program.
  ( remember in C and C++ argv[0] ???  ,  there it really is! neat huh... )

The pointer to that argument (which is a string) will be at the next item up
on the stack.  I don't want to get into handling command line args at this
point other than to to mention that arg storage and retrieval is another
important function of the stack.  Briefly, as I said the CL arguments are
stored as strings and pointers to these strings are stored on the stack
leading up to the final argc whch we see there in ebp as 1.

Now remeber epb was left with that address loaded.  So I can refer upward in
memory to retrieve those values. xamine works well for that too.
First we need the address and work from that so I look 4 bytes up for that:

(gdb) x /xw $ebp + 4
0xbfd4eff4:     0xbfd4fbbd

Now use  /s format to print the zero terminated string found at that address.

(gdb) x /s  0xbfd4fbbd
0xbfd4fbbd:      "/home/howard/asm/myex/zat-24"

Or we can dereference that stack address:
Remember ebp held 0xbfd4eff0 ?  Well, we can add 4 to that manually and do:

(gdb) x /s *0xbfd4eff4
0xbfd4fbbd:      "/home/howard/asm/myex/zat-24"

Is  that cool? The * means dereference the address found at that address (how C like : )
If there were more command line args you would go up 4 more for each address.
That's enough on CL args... There was a thread not too long ago on that.(in nasm)
Before moving on, we can take a look up over our stack memory byte by byte too:

(gdb) x /16xb $esp
0xbfd4efe8:     0x33    0x22    0x00    0x00    0x11    0x00    0x00    0x00
0xbfd4eff0:     0x01    0x00    0x00    0x00    0xbd    0xfb    0xd4    0xbf

And we can match that up with this:

(gdb) x /4xw $esp
0xbfd4efe8:     0x00002233      0x00000011      0x00000001      0xbfd4fbbd

There are the values we pushed, argc , and argv[0]...
Something to note here is the address shown in argv[0].
We can subtract to see how far away it is located.  Lets see,
(Here is a bonus: math on the Linux shell command line: )

[howard@mybox myex]$ echo $[0x4fbbd - 0x4efe8]
3029

Well that's not very close by... like 3k away. Ok, let's move on...
Where was I... oh yeah beginning to pop values from the stack.
The last steps we took were:

(gdb)
_start () at zat-24.s:13
13        pushl $0x2233         <--- last step executed taken before
4: /x $eax = 0x0
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efec
1: /x $ebp = 0xbfd4eff0

(gdb) s
_start () at zat-24.s:16
16        popl  %eax
4: /x $eax = 0x0
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efe8        <--- esp incremented by pushl
1: /x $ebp = 0xbfd4eff0

(gdb) s
_start () at zat-24.s:17
17        movb  (%esp),  %al
4: /x $eax = 0x2233            <--- the popped value is in eax
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efec        <--- esp decremented by popl
1: /x $ebp = 0xbfd4eff0

(gdb)
18        popl  %eax
4: /x $eax = 0x2211            <--- note how movb effected only the al byte
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4efec        <--- esp NOT decremented by movl
1: /x $ebp = 0xbfd4eff0

(gdb)
_start () at zat-24.s:21
21        movb $0, %bl
4: /x $eax = 0x11              <--- the final popl overwrote a all bits of eax
3: /x $ebx = 0x0
2: /x $esp = 0xbfd4eff0        <--- esp is back to original value
1: /x $ebp = 0xbfd4eff0

Ok, now I tried to note the points of interest with <--- comments above.
If you can follow along you see how the value of esp is back to where we began.
It is important to note that while the pointer is back the values placed out
in our stack 'frame' are still there.  Let's see:

(gdb) x /4xw $esp - 8
0xbfd4efe8:     0x00002233      0x00000011      0x00000001      0xbfd4fbbd

Yes they are , and will remain there until overwritten by subsequent pushes.
I'm not sure about how much of a security issue this could is to the pros.
I suppose you could push and pop zeros if you needed to be sure...
Note that I had to start the xamine print at esp - 8.  Know why!
I know it's confusing, but it's important to understand.
The more I play around with the stack the more I feel more comfortable

Ok so that's yer basic stack.  Hope it helps...
Now, as you move  into the 'power.s' function example keep in mind how I moved
esp value to ebp and used it as a base pointer and how the command line
argument was placed on the stack immediatly before that original esp address.
That is very similar to the C calling convention he demonstrates in power.s.

I'd recommend you experiment with this program until you are comfortable with
the pushes and pops , and then move to the power function and step through it
very slowly displaying all the register values concerned.  Make sure you understand each step before you move to the next one... etc.
Give it some time to soak in , you'll get it...

The EIP register (Instruction Pointer) holds the address of the next
instruction to be executed. It can be manipulated as you will see in the
power.s function example.  But if you want to view it in this example just use:
p $eip
or
display $eip    To dislplay it at every step.

For example: 
(gdb) step
_start () at zat-24.s:12
12        pushl $0x11        #Note that esp value (an address) is decremented with each
3: /x $eax = 0x0
2: /x $esp = 0xbfcac750
1: /x $ebp = 0xbfcac750
(gdb) p $eip
$1 = (void (*)()) 0x8048077 <_start+3>

You can use this to display the address for each instruciton of the entire code:

(gdb) disassemble
Dump of assembler code for function _start:
0x08048074 <_start+0>:  nop
0x08048075 <_start+1>:  mov    %esp,%ebp
0x08048077 <_start+3>:  push   $0x11
0x08048079 <_start+5>:  push   $0x2233
0x0804807e <_start+10>: pop    %eax
0x0804807f <_start+11>: mov    (%esp),%al
0x08048082 <_start+14>: pop    %eax
0x08048083 <_start+15>: mov    $0x0,%bl
0x08048085 <_start+17>: mov    $0x1,%eax
0x0804808a <_start+22>: int    $0x80
End of assembler dump.

You will also see the offset values like <_start+3>.
Now, if you used the compiling line with the -a  and  > zat-24.listing  it
should have produced a file by that name: zat-24.listing
That file will show some related interesting things as well. Mine looks like this:
----------
GAS LISTING zat-24.s                    page 1
   1                    .section .bss
   2                       .lcomm buf1, 8          #set aside 8 bytes
   3                    .section .data
   4 0000 01020304         num1: .int 0x04030201   #a 4 byte integer
   5                    .section .text
   6                    .global _start
   7                    _start:
   8 0000 90              nop
   9                      #Step through all these with gdb
  10
  11 0001 89E5            movl %esp , %ebp   #Get beginning stack location to ebp.
  12 0003 6A11            pushl $0x11        #esp value  decremented with each
  13 0005 68332200        pushl $0x2233      #push while ebp's value stays same
  13      00
  14 000a 58              popl  %eax         #gets the last pushed value into eax
  15                      #### STOP 1
  16
  17 000b 8A0424          movb  (%esp),  %al  #moves only 1 byte to al
  18 000e 58              popl  %eax          #same as above
  19                      #### STOP 2
  20
  21 000f B300            movb $0, %bl
  22 0011 B8010000        movl $1, %eax
  22      00
  23 0016 CD80            int $0x80
----------

So in that see column 1 is line number, column 2 is the offset, column 3 is the actual machine code to accomplish the human instruction which follows. nifty...
Note that these offset values are the same as the disassembly output.


Now what else did I want to say...  Oh yeah, storage areas and addresses...
I pointed out that the argv[0] address was in a certain area of memory.
I think it is interesting to imagine how the whole program exsists in memory.
I'm not sure how to get a dump on that but I can definitely  see some other
addresses and get a general picture by lining them up.

You may have noted that I declared some .bss and .data  data space in the prog.
.section .bss
   .lcomm buf1, 8          #set aside 8 bytes (zeroed) we can refer to as buf1
.section .data
   num1: .int 0x04030201   #a 4 byte integer

We can look at those addresses too , and along with that we can see the
address the code runs from and to as well. So I'll get some of them:
(gdb)    info address buf1
Symbol "buf1" is at 0x8049090 in a file compiled without debugging.
(gdb)    info address num1
Symbol "num1" is at 0x804908c in a file compiled without debugging.
(gdb) info address _start
Symbol "_start" is at 0x8048074 in a file compiled without debugging.
(gdb) info address _end
Symbol "_end" is at 0x8049098 in a file compiled without debugging.

So lining up some of those values I start to get a picture:
0xbfd4eff0    the stack base
3k gap
0xbfd4fbbd    argv[0]
  big-A gap
0x08048074     _start and first instruction
0x0804808a     last instruction  (as seen in dissassembly output)
0x0804908c     .data data num1 (4 bytes)
0x08049090     .bss  data buf1 (8 bytes)
0x08049098     _end    (hey I declared no _end... but it fits right in)

So I think you will agree , I need a life,,, NO I mean that is interesting. 

And finally in that vein... 
In case you weren't aware of it, these addresses we see are NOT the ACTUAL
memory addresses.  They are 'virtual addresses'.
The operating system assigns us a value and our code offsets are added to that.
Those are the values we see.  The reason for this is that it wants to keep the
real address a secret... (I kid , well maybe partially) but really, it is so the OS can move our program around. It can be plopped at one place of memory ,
swapped out to the hard drive to create space for some web crap, and swapped
back in after we finally kill that process and get our machine back!!!
At least thatis what I think... something like that.
Of course, this is ALL conjecture on my part...

(gdb) p $eip
$1 = (void (*)()) 0x8048077 <_start+3>

gdb) p $eip
$1 = (void (*)()) 0x8048077 <_start+3>