Para ser un poco mas bruto... tenemos suficiente masa cerebral para ir y reimplementar algo como GCC y glibc en N plataformas? Es un laburo *denso*... e igual no te salvas de leer la documentacion de turno!
2011/4/7 Andres Valloud <[email protected]>: > Y... como poder seguro que se puede... o sea, podes implementar un > compilador de C y generarte tus propios exes para todas las > plataformas etc (asumiendo que queres usar un sistema operativo que > escribio otro). Ahora, vale la pena todo ese trabajo cuando, con > considerablemente menos esfuerzo y mantenimiento, podes usar lo que > hicieron los demas? > > 2011/4/7 Javier Burroni <[email protected]>: >> Hola, >> no se si un smalltalk se puede escribir en smalltalk; pero un Mark & >> compact, y un GC generacional, me consta que sí :) >> (perdón, pero justo coincidió el thread con otra cosa del universo) >> >> 2011/4/5 Hernan Wilkinson <[email protected]>: >>> Andres, >>> tu razonamiento es muy similar al que tenía la gente en el 50 (sin >>> ofender eh!) cuando prefería escribir código assembler en vez de >>> utilizar lenguajes de "alto nivel" porque el "compilador no era tan >>> bueno como las personas" para escribir código performeante, etc. O >>> sea, yo entiendo lo que decis y en ciertos puntos concuerdo que hay >>> que escribir código C, pero seguramente en la mayorías de los casos el >>> C generado automáticamente puede ser lo suficientemente bueno o aún >>> mejor de lo que podría escribir una persona... por supuesto que no es >>> lo mismo traducir leng. alto nivel a assembler que smalltalk a C (está >>> la diferencia de abstracción que cada uno maneja), pero me suena a un >>> problema similar. >>> >>> Un abrazo >>> Hernan. >>> >>> 2011/4/4 Andres Valloud <[email protected]>: >>>> No estoy muy convencido de que cualquier cosa en C se pueda escribir >>>> en Smalltalk que eventualmente se traduce a C. De hecho, me parece >>>> tanto quilombo hacer eso que prefiero escribir las O(100) lineas de C >>>> que hagan falta, cumplir con la especificacion de turno, y listo. Ojo >>>> que cuando digo esto estoy pensando en cosas que tienen que ver con la >>>> plataforma, no necesariamente un JIT. >>>> >>>> 2011/4/4 Guillermo Schwarz <[email protected]>: >>>>> A eso justamente iba. Si debe estar en c es porque desde smalltalk no >>>>> puedo hacer referencia a una posición en memoria, que es justamente como >>>>> se manejan los signals. >>>>> >>>>> En squeak hay una manera de traducir smalltalk a c. Cada mutex de >>>>> smalltalk debiera ser traducible a un mutex de c. >>>>> >>>>> Saludos, >>>>> Guillermo Schwarz. >>>>> >>>>> El 03-04-2011, a las 4:17, Andres Valloud <[email protected]> >>>>> escribió: >>>>> >>>>>> Me refiero a los mutexes que tienen que estar escritos en C, por >>>>>> ejemplo los de los signal handlers o los de los foreign callbacks. >>>>>> >>>>>> 2011/4/2 Guillermo Schwarz <[email protected]>: >>>>>>> Estoy 100% de acuerdo en lo que dices, excepto en eso de que "si los >>>>>>> mutexes están escritos en c, le dan poca bola, si están escritos en >>>>>>> smalltalk no les van a dar nada", ya que mientras mas alto es el nivel >>>>>>> del lenguaje mas evidente se hacen todas esas cosas y es mas fácil >>>>>>> arreglarlas. >>>>>>> >>>>>>> Saludos, >>>>>>> Guillermo Schwarz. >>>>>>> >>>>>>> El 02-04-2011, a las 17:33, Andres Valloud <[email protected]> >>>>>>> escribió: >>>>>>> >>>>>>>>> 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 >>>>>>> >>>>>>> -- >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> >>>>>>> http://www.clubSmalltalk.org >>>>>> >>>>>> -- >>>>>> To post to this group, send email to [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected] >>>>>> >>>>>> http://www.clubSmalltalk.org >>>>> >>>>> -- >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> >>>>> http://www.clubSmalltalk.org >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> http://www.clubSmalltalk.org >>> >>> >>> >>> -- >>> Hernán Wilkinson >>> Agile Software Development, Teaching & Coaching >>> Mobile: +54 - 911 - 4470 - 7207 >>> email: [email protected] >>> site: http://www.10Pines.com >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >> >> >> >> -- >> " To be is to do " ( Socrates ) >> " To be or not to be " ( Shakespeare ) >> " To do is to be " ( Sartre ) >> " Do be do be do " ( Sinatra ) >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
