TecnoFe

¿Preincrementar o postincrementar?

2008-08-19T09:34:00+00:00

Hace mucho que quería escribir un post tan inútil como este. La duda que siempre me pasaba por la cabeza era la siguiente: ¿Será exactamente el mismo código ensamblador el que genera el compilador cuando utilizamos el preincremento o el postincremento (sin utilizar el valor de retorno)? Tenía la seguridad de que así debía ser (una optimización tan básica no podía ser dejada de lado), pero me faltaban las pruebas (en ensamblador) para verificarlo.

Recordando un poco, el preincremento

int a = 0;
int b = ++a;

hace a=1 y b=1, mientras que el postincremento

int a = 0;
int b = a++;

hace a=1 y b=0, esto significa que b obtuvo el valor de a anterior al incremento.

Aquí estamos utilizando el valor de retorno del operador incremento. El código ensamblador es distinto para cada caso. Vamos a echarle una mirada (antes le recomiendo ver este excelente artículo para comprender más sobre el stack y las convenciones de llamadas). En el preincremento el código ensamblador (generado por GCC 3.4.5 para i386) es:

subl $8, %esp // reservamos 8 bytes en el stack (para variables locales)
movl $0, -4(%ebp) // a = 0
leal -4(%ebp), %eax // eax = &a
incl (%eax) // *eax= (*eax) + 1
movl -4(%ebp), %eax // eax = a
movl %eax, -8(%ebp) // b = eax

En el postincremento

subl $8, %esp // reservamos 8 bytes en el stack
movl $0, -4(%ebp) // a = 0
movl -4(%ebp), %edx // edx = a
leal -4(%ebp), %eax // eax = &a
incl (%eax) // *eax= (*eax) + 1
movl %edx, -8(%ebp) // b = edx

donde se ve que el registro edx se utiliza para guardar el valor que tenía a antes del incremento para luego asignárselo a b.

Pero la pregunta original es, ¿qué pasa si no usamos el valor de retorno? ¿el código de ++i o i++ es igual? Debería serlo, y de hecho, lo es. Pero como veremos más abajo, esto sólo se cumple si utilizamos tipos de datos built-in (int, double, long, etc.). Miremos el siguiente código:

void func() { }
void pre () { for (int c=0; c<8; ++c) { func(); } }
void post() { for (int c=0; c<8; c++) { func(); } }
int main()
{ pre(); post(); return 0;
}

Básico, un for pero con las dos variantes posible de incremento. El código generado para ambos casos (tanto para la función pre como post) es el siguiente:

 pushl %ebp // guardar el viejo puntero a la base del stack movl %esp, %ebp // establecer la nueva base del stack subl $4, %esp // guardar 4 bytes en el stack (para variables locales) movl $0, -4(%ebp) // c = 0
L3: cmpl $7, -4(%ebp) jg L2 // si c > 7 entonces ir a L2 call _func // llamar a la función func() leal -4(%ebp), %eax // eax = &c incl (%eax) // *eax= (*eax) + 1 jmp L3 // repetir yendo a L3
L2: leave // restaurar la base del stack (popl %ebp) ret // retornar al punto de llamada

Realmente es indiferente usar cualquiera de los dos tipos de incremento, salvo, en los tipos definidos por el usuario. C++ ofrece un soporte para tipos de usuario igual a los built-in (bueno, no del todo, pero lo están solucionando). Nos da la posibilidad de sobrecargar los operadores de nuestros propios tipos (clases). Por ejemplo:

class tipo { int x;
public: tipo(int y) : x(y) { } tipo(const tipo& y) : x(y.x) { } // preincremento tipo& operator++() { ++x; return *this; } // postincremento tipo operator++(int) { tipo tmp(*this); ++x; return tmp; } bool operator<(int y) const { return x < y; }
}; void func() { }
void pre() { for (tipo c=0; c<8; ++c) { func(); } }
void post() { for (tipo c=0; c<8; c++) { func(); } } int main()
{ post(); return 0;
}

No colocaré el código ensamblador por desbordar belleza, pero el código generado en este caso es distinto: cada incremento llama a la función correspondiente a su operador. Esto es debido a que ambas implementaciones varían considerablemente. Por ejemplo, el postincremento necesita de una instancia extra de tipo para poder devolver el anterior valor de this, en cambio, el preincremento devuelve una referencia al mismo this (sin necesidad de hacer una copia).

Como dato curioso, algo interesante ocurre al utilizar las optimizaciones del GCC. Si compilamos este último programa con el parámetro -O3, vamos a ver que todas las funciones correspondientes a la clase tipo desaparecen, y todo el código resultantes es inline, dando como resultado un código tan óptimo como si hubiéramos utilizado un int en vez de nuestra clase tipo.

¿Cómo obtengo el código ensamblador desde un archivo C/C++?
Con el compilador gcc, hay que utilizar el parámetro -S:

g++ -S -o archivo.s -c archivo.cpp

En archivo.s queda el código ensamblador (sintaxis AT&T).

Fotografiando desde el camino

2008-08-18T16:59:45+00:00

Hace unos días empecé a publicar fotos instantáneas en mi blog. Basándome en el servicio gratuito de Personal puedo tener en mi blog, en menos de un minuto, fotos que tome con mi celular.

Album Personal es un servicio que te permite subir sin cargo fotos desde tu celular a un espacio privado en la web. Una vez que las fotos están ahí puedo jalarlas (pool) al servidor dónde está alojado mi blog.

Este procesos de pooling es llevado a cabo mediante un script escrito en Python (sirviéndome de las librerías BeautifulSoup, urllib2 y cookielib) que puedo ejecutar directamente desde mi celular utilizando MidpSSH (un cliente ssh escrito en Java para celulares).

Por ahora solo se visualiza la última foto que subo en la página principal del blog. Pronto voy a implementar un álbum desde el cual ver también las fotos anteriores.

Podés estar seguro que no entendiste el Proceso Unificado cuando…

2008-08-14T18:04:41+00:00

Un extracto del Libro de Larman (Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition) mientras termino un post donde resumimos largas charlas presenciales y virtuales con Milton acerca de las metodologías para el desarrollo de software.

2.13. You Know You Didn’t Understand Iterative Development or the UP When…

Here are some signs that you have not understood what it means to adopt iterative development and the UP in a healthy agile spirit.

You try to define most of the requirements before starting design or implementation. Similarly, you try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing.
You spend days or weeks in UML modeling before programming, or you think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail. And you regard programming as a simple mechanical translation of these into code.
You think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing the waterfall on the UP).
You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
You believe that a suitable iteration length is three months long, rather than three weeks long.
You think that adopting the UP means to do many of the possible activities and create many documents, and you think of or experience the UP as a formal, fussy process with many steps to be followed.
You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.

Destaco por ahora la ante última oración para los detractores y que dicen que es poco ágil.

Más información acerca del UP, Rational UP, y otras “instancias” del UP.

http://www.agilemodeling.com/essays/agileModelingRUP.htm

Nuevo número de celular

2008-08-09T21:39:28+00:00

Desde ayer a la tarde tengo un nuevo número de celular. Aproveché el viaje de hoy a Pellegrini para enviar un mensaje masivo a todos mis contactos del viejo celular comunicándoles mi nuevo número.

¿No te lo mandé? ¿Debería haberlo hecho? Mandame un mail y te lo paso!