]> git.llucax.com Git - z.facultad/75.00/informe.git/blobdiff - informe.rst
Corregir Limitaciones en la Introducción
[z.facultad/75.00/informe.git] / informe.rst
index a3563dec9f0577b8db603fd21cecae35c2f5fb84..2d168017212a541ad88450c9f6112c8b06830d83 100644 (file)
@@ -172,7 +172,7 @@ un "C++ mejor", ya que el objetivo del lenguaje es muy similar a C++,
 pero implementa muchas características que jamás pudieron entrar en
 el estándar de C++ y lo hace de una forma mucho más limpia, ya que
 no debe lidiar con problemas de compatibilidad hacia atrás, y cuenta
-se con la experiencia del camino recorrido por C++, pudiendo extraer de
+con la experiencia del camino recorrido por C++, pudiendo extraer de
 él los mejores conceptos pero evitando sus mayores problemas también.
 
 Una de las características que nunca pudo entrar en el estándar de C++
@@ -188,51 +188,47 @@ Objetivo
 La recolección de basura en D_ es un problema prácticamente nuevo. Si bien
 pueden considerarse válidos todos los modelos propuestos para recolección
 de basura en C, estos son muy restrictivos y poco eficientes, por lo
-promiscuo que este lenguaje.
-
-Por otro lado, la recolección de basura en C y C++ está prácticamente
-restringida a implementaciones a nivel de bibliotecas, ya que la inclusión
-de un recolector de basura en el estándar de C/C++ es algo que no va a
-pasar por largo tiempo. Entonces quedan dos caminos posibles:
-
-1. Quedarse con las limitaciones de un recolector de basura a nivel de
-   bibliotecas, lo que es muy restrictivo.
-2. Construir una solución a nivel de compilador que no cumpla con el
-   estándar y que no pasará de ser una curiosidad académica.
-
-La primera opción está ya bastante desarrollada y es casi un sinónimo de un
-recolector de basura conservativo. La segunda, no es un objetivo viable para
-una Tesis de Ingeniería, donde se pretende llegar a un resultado lo más
-práctico posible (hacer un aporte más ingenieril que científico).
-
-Por lo tanto el objetivo es abordar la segunda opción sobre un lenguaje que
-es propenso a absorver nuevas ideas y cambios. Un lenguaje que es además,
-mucho más rico sintáctica y semánticamente, sin perder utilidad práctica ni
-eficiencia para cumplir las tareas para las cuales C y C++ fueron
-diseñados.
-
-Se propone entonces en este trabajo, desarrollar un recolector de basura
-para un lenguaje de programación imperativo compilado, con tipado estático
-y enlazable con C (siendo esto último probablemente uno de los desafíos más
-importantes), agregando soporte al lenguaje o al compilador (de ser
-necesario) y utlizando las características avanzadas que el lenguaje
-provee.
+promiscuo que este lenguaje. Por otro lado D_ provee muchas construcciones
+de alto nivel, lo que hace que la necesidad de utilizar construcciones de
+bajo nivel sea muy escasa, por lo tanto brinda un campo importante a
+explorar en cuanto a mejoras para el recolector de basura.
+
+Por lo tanto el objetivo del presente trabajo puede resumirse en los
+siguientes puntos:
+
+- Investigar y analizar la viabilidad de mejoras al recolector de
+  basura de D_, tanto mejoras menores dentro de las limitaciones actuales
+  del lenguaje (incluyendo pero no limitado a mejoras en el algoritmo
+  actual de recolección y soluciones en *espacio de usuario* -como
+  biblioteca-), como proponiendo mejoras al lenguaje que permitan la
+  implementación recolectores más precisos y eficientes.
+- Elegir un conjunto de las mejores soluciones halladas e implementarlas.
+  Las soluciones que necesiten modificaciones en el lenguaje serán
+  implementadas modificando el compilador libre de D_ GDC_, que
+  también será utilizado como plataforma principal de desarrollo y
+  prueba (debido a la disponibilidad completa del código fuente y
+  la libertad de usarlo y modificarlo libremente). De todas formas,
+  siempre se priorizarán las modificaciones al *frontend* [#frontend]_
+  sobre las modificaciones al *backend*, permitiendo así que las mejoras
+  puedan ser probadas eventualmente en otros compiladores que utilicen
+  el *frontend* publicado por DigitalMars_, como DMD_.
+- Realizar pruebas sobre aplicaciones lo más variadas y reales posible
+  sobre todas las soluciones implementadas, de manera de determinar de
+  forma fehaciente las ventajas de unas y otras en cuanto a latencia,
+  consumo de memoria, consumo de procesador, tiempos de pausa, etc.
+- Presentar las conclusiones obtenidas del análisis y las pruebas
+  realizadas, tanto en el ámbito académico de la facultad como a la
+  comunidad de D_ (con el objetivo de sumar lo construido en este trabajo
+  al lenguaje).
+
+.. [#frontend] El *frontend* es el módulo del compilador que realiza el
+   análisis sintáctico y semántico del lenguaje. GDC_ utiliza como
+   *frontend* el que provee libremente DigitalMars_.
+.. [#backend] El *backend* es el módulo del compilador que emite
+   el código binario (o *assembly*, o el lenguaje que produzca el
+   compilador como resultado final). GDC utiliza el *backend* del GCC_
+   (*GNU Compiler Collection*), uno de los compiladores más populares.
 
-.. INTRODUCCION ..............................................................
-
-Alcance
--------
-.. Alcance de la tesis, qué se pretende hacer
-   ESTADO: TERMINADO, EN REVISION
-
-En esta tesis se plantea desarrollar un recolector de basura para el
-lenguaje de programación D, utilizando como plataforma el compilador GDC_.
-El objetivo es conseguir un recolector de basura eficiente, en tiempo y
-espacio, aunque priorizando lo primero. Como objetivo secundario se propone
-obtener una recolector configurable, para poder elegir los parámetros que
-mejor se ajusten al problema particular.
-
-.. _GDC: http://dgcc.sourceforge.net/
 
 .. INTRODUCCION ..............................................................
 
@@ -246,10 +242,11 @@ objeto C, y por lo tanto interactuar directamente con éste, habrán
 limitaciones en el recolector resultante con respecto a esto. En este
 trabajo se busca lograr un recolector que sea eficiente para casos en donde
 el código que interactúa con C esté bien aislado, por lo que estas
-porciones de código pueden quedar por fuera del recolector de basura.
+porciones de código pueden quedar por fuera del recolector de basura o
+necesitar un manejo especial.
 
-De otra forma probablemente se llegaría a un recolector conservativo y
-simple como el que está disponible en la actualidad.
+De no plantear esta limitación se llegaría indefectiblemente a un recolector
+conservativo como el que está disponible en la actualidad.
 
 .. ===========================================================================