> En resumen, coincido con vos. Tal vez mi post no fue tan claro como yo > quise. Mi punto de vista era que el hecho de que esté escrita en SLANG está > buenísimo para que cualquier boludo
No no no :)... > cómo yo, la pueda > navegar/refactorizar/simular usando las herramientas mismas de Smalltalk. Eso esta bueno. A mi por ejemplo me gustaria tener senders / implementors en vez de usar grep. Aunque grep tambien tiene lo suyo. > Ponele si yo miro el interp.c (el archivo resultado de la transformación de > SLANG a C), y pienso que tengo que entender/modificar eso, me pego un tiro. > Claro, es autogenerado, así que supongo que si está hecho todo manual es > otra cosa, pero igual... Y si... eso no es facil. A mi lo que me da un poco de impresion es que si esta autogenerado entonces no se le pasa tanta bolilla desde el punto de vista de C por la razon que decis... es un quilombo. Hace varios años cuando estaba en Exobox (que te pario ya soy un fosil!!!) me acuerdo que despues de la primera conversion venia otra que hacia inline de todo 9 veces seguidas, socorro... lo que me da un poco de cosa es el tema de los tipos, los bitfields con GCC, las cosas que no estan especificadas como hacer bitshift a la izquierda de un entero negativo mas veces que la cantidad de bits en el entero... ... o sea, en C el resultado de esta operacion depende del compilador: int k = -1; return k << 40; Ojo, para valores positivos la especificacion dice exactamente que tiene que pasar, pero para valores negativos, no. En algunos casos vi cero, y en otros vi como el shift se hacia rotativo y los bits que se caian de un lado aparecian en el otro. Estaba tentado de pensar que el compilador era una basura, pero me fije en la especificacion de C (se llama C99), y... y dice claramente que el resultado en ese caso no esta especificado. Esta clase de cosas son jodidas, y encima hay un monton. Que se yo, tambien hay una region gris donde se asume que la implementacion va a ser razonable. Uno se la pasa asumiendo que los punteros se pueden comparar independientemente de la direccion a la que apuntan. Sin embargo, la comparacion de punteros tampoco esta especificada si los punteros en cuestion no apuntan a datos del mismo array (o, como mucho, &(a[x]) si el array tiene tamaño x). En algun lado dice que todos los programas en C tiene *un* stack --- asi que por ejemplo tener stacks "nativos" en un JIT es una violacion de la especificacion correspondiente. Y sin embargo, la cosa anda porque las implementaciones en C son lo suficientemente flexibles (o, dicho de otro modo, no son tan estrictas) como para que cosas interesantes funcionen igual. Por eso hay que tener mucho cuidado, despues uno le termina tirando la culpa de que el programa no anda a algun misterioso "bug del compilador" demasiado facil... > No cabe duda de que hay muchísimas partes que se tienen que hacer directo en > C: cuestiones de performance, cuando depende de la plataforma, etc etc etc. O lo que rompe mucho la paciencia hacer en el JIT, como por ejemplo la primitiva del become: en particular cuando tenes un modelo de memoria complejo. En VisualWorks hay 15 casos, y encima hay que pensar mucho que pasa cuando el IGC esta funcionando y haces cosas como strongObject become: weakObject o weakObject become: anEphemeron Ya en C eso es un ***bardo***. Escrito en un JIT... ay que dolor. > Más allá de eso, la simulación para muchos es terriblmente inpagable. > Ponele, si le preguntás a Eliot (por lo que me comentó en la Smalltalk o en > la Deep Smalltalk, no me acuerdo), está CHOCHO con poder simular la VM. De > hecho, puso bocha de esfuerzo en el simulador (incluso para la JIT). El tema de simular los metodos nativos y todo eso debe ser mucho mas agradable que gdb (o, mucho peor, WinDBG). Pero tambien hay que tener en cuenta que seguramente en esa simulacion el tema de signals e interrupciones no es una simulacion fiel de lo que pasa en realidad. Por ejemplo, que pasa cuando hay que boletear el stackLimit de un stack desde un signal handler? Y que pasa si la interrupcion cae mientras la maquina virtual (en C) esta cambiando los stack pages? Entonces se te cae un pedido de interrupcion al piso y la maquina virtual lo ignora. Arreglar esa clase de bugs es muy dificil porque la mayoria del tiempo parece que las cosas funcionan. Esto pasa en VisualWorks... lo tengo un poco arreglado, pero hay otro bug relacionado que aun no encontre (basicamente, podes hacer que un proceso de prioridad menor le haga siempre un preempt a varios procesos de prioridad superior, lo que esta claramente muy mal), y entonces no se si el tema del stackLimit esta arreglado del todo o no. Mientras tanto, hace mas de una decada que ***parece*** que funciona. Y sin embargo que no existan esos problemas, que no haya problemas con secciones criticas sin proteccion de mutex, que no haya violaciones groseras de la especificacion relevante... todas esas cosas que en C las tenes a flor de piel son hiper importantes para que despues uno pueda decir que la maquina virtual anda. Me preocupa que si ya hoy mucha bolilla no se le pasa a esos temas de C, entonces mañana si esta escrito en Smalltalk entonces menos bolilla se le va a pasar. Arreglar los parches que se acumulan con los años para hacer que las cosas ***parezcan*** funcionar es un requilombo... si con un cambio haces que el bug que te pasaba una vez cada 5 minutos ahora pase cada 6 meses, mejor no cambies nada hasta no encontrar el bug. Andres. -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
