-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 00:47 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 00:38:21 +0100, Carlos E. R. escribió:
El 2010-01-30 a las 19:50 -0000, Camaleón escribió:
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
No es sólo cuestión de colorines, es que hay que analizar el contenido. En cierto sentido, se parece mucho a lo que tiene que hacer el programa analizador de verdad.
Qué va. No, el contenido no.
Sólo tiene que comparar en su bdd de etiquetado interno si coincide con las marcas que lee en el documento y aplicar un formato distinto, pero no analiza el contenido.
En cierto modo, sí. Hay programas que cambia el coloreado si la sintaxis es incorrecta. Lo tipico es comenzar un color en token de apertura, y terminarlo en el de cierre, para lo cual debe analizar el texto, para no disparar el cierre dentro de un comentario o de un string, que parece el token de cierre sin serlo. Luego están las facilidades de los editores como, dependiendo de en que sección estás, autocompletar, seleccionando lo que puedes añadir dependiendo del contexto, para lo cual debe analizarlo. No es un analizado completo, pero sí parcial; y un análisis aunque sea parcial puede hacerse un lio y colgarse. Por otra parte, que parece que es el caso, al diseñar un editor hay dos estrategias principales: estructurar linea a linea (con lo que sueles tener un límite de tamaño de linea, fijo o variable), o estructurar por buffer de caracteres contínuo, con lo que se complica el subir y bajar por el fichero pero minimiza el uso de memoria.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no.
No tendría sentido tener 8, 16 o 32 GiB. de RAM y sólo poder destinar 4 GiB a un sólo proceso ¿no...? Estoy pensando en servidores con bases de datos gigantescas o el estaciones de trabajo de renderizado 3D :-?
Pues tiene sentido, porque es lo que el procesador puede direccionar internamente. Para acceder a más hay que mapear, y el programa ha de ser consciente de que está en ese tipo de sistema. Y si tienes bases de datos gigantescas (en memoria, ojo), pues es que no te conviene un sistema de 32 bits.
A ver qué dice la wikipedia¹:
*** address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a flat memory model) is limited to 4 gigabytes of virtual address space.
Eso es lo que digo.
The operating system uses page tables to map this 4 GB address space into the 64 GB of physical memory. The mapping is typically applied differently for each process. In this way, the extra memory is useful even though no single regular application can access it all simultaneously.
Exacto.
For application software which needs access to more than 4 GB of RAM, some special mechanisms may be provided by the operating system in addition to the regular PAE support. On Microsoft Windows this mechanism is called Address Windowing Extensions, while on Unix-like systems a variety of techniques are used, such as using mmap() to map regions of a file into and out of the address space as needed.
Eso son los trucos que digo de los que el programa ha de ser consciente.
***
El último párrafo parece indicar que una aplicación sí puede acceder a más de 4 GiB. mediante la función mmap() :-?
Sí, indirectamente, y con perdida de eficacia. Son trucos muy viejos: recuerda que hubo un tiempo en que los procesadores eran de 8 bits y sólo podían redireccionar 64 kilobits. El mapeo podía hacerse con registros de memoria externos, multiplexadores, y otros trucos "horribles". El procesador podía pedir una dirección 32000, y en su lugar recibía la 132000, sin saberlo, porque un chip cambiaba los cables del bus de direcciones de memoria en la placa. Ahora son más limpios, pero la idea básica es parecida. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktk36wACgkQtTMYHG2NR9WEWgCfU/rmjEYSsics+pdUwgL2hn7c 5AgAn1XuV2Hu9Ko/8+8migSL7jB5bsDr =y6DO -----END PGP SIGNATURE-----