LLVM es una marco para el desarrollo de compiladores ademas de que ayuda a construir nuevos lenguajes de programación y mejorar los lenguajes existentes

Después de poco más de seis meses de desarrollo, se dio a conocer el lanzamiento de la nueva versión del proyecto LLVM 16.0, versión en la que se implementan una gran cantidad de cambios y mejoras.

Para quienes desconocen de LLVM, deben saber que este es un compilador compatible con GCC (compiladores, optimizadores y generadores de código) que compila programas en un código de bits intermedio de instrucciones virtuales tipo RISC (una máquina virtual de bajo nivel con un sistema de optimización multinivel).

El pseudocódigo generado puede ser convertido por el compilador JIT en instrucciones de máquina justo en el momento de la ejecución del programa.

Principales novedades de LLVM 16.0

En esta nueva versión que se presenta, podremos encontrar diversas mejoras importantes en Clang 16.0, de las cuales de destaca el estándar C++/ObjC++ predeterminado que se establece en gnu++17 (anteriormente gnu++14), lo que implica soporte para funciones de C++17 con extensiones GNU de forma predeterminada. En el código LLVM se permite el uso de elementos definidos en el estándar C++17.

Otro de los cambios que se destaca, es que se ha agregado soporte para CPU Cortex-A715, Cortex-X3 y Neoverse V2, extensiones Armv8.3 y funciones de versiones múltiples al backend AArch64.
La compatibilidad con las plataformas Armv2, Armv2A, Armv3 y Armv3M se suspendió en el backend de la arquitectura ARM, para el cual no se garantizaba la generación correcta de código. Se agregó la capacidad de generar código para instrucciones para trabajar con números complejos y se agregó soporte para arquitecturas de conjuntos de instrucciones (ISA) AMX-FP16, CMPCXADD, AVX-IFMA, AVX-VNNI-INT8, AVX-NE-CONVERT al backend X86.

Ademas de ello, se han aumentado los requisitos para construir LLVM, ademas de que la compilación ahora debería ser compatible con el estándar C++ 17, es decir, la compilación requiere al menos GCC 7.1, Clang 5.0, Apple Clang 10.0 o Visual Studio 2019 16.7.

Por otra parte, tambien se destacan los backends mejorados para arquitecturas MIPS, PowerPC y RISC-V, asi como tambien el soporte para depurar ejecutables de 64 bits para la arquitectura LoongArch al depurador LLDB y el manejo mejorado de los símbolos de depuración COFF.

De los demás cambios que se destacan:

• En la biblioteca Libc++ , el trabajo principal se centró en implementar soporte para nuevas características de los estándares C++20 y C++23.
• El tiempo de enlace se ha reducido significativamente en el enlazador LDD al paralelizar el escaneo de reubicación de direcciones y las operaciones de inicialización de secciones. Se agregó soporte para la compresión de secciones usando el algoritmo ZSTD.
• Tambien se destacan las funciones avanzadas implementadas con el estándar C++20.
• capturar enlaces estructurados en funciones lambda.
• El operador de igualdad dentro de expresiones.
• Capacidad para no especificar la palabra clave typename en algunos contextos,
• Permisibilidad de la inicialización agregada entre paréntesis («Aggr(val1, val2)»).
• Funciones implementadas definidas en el futuro estándar C++2b.
• Compatibilidad proporcionada con el tipo char8_t,
• Se amplió el rango de caracteres permitidos para su uso en «\N{…}»,
• Se agregó la capacidad de usar variables declaradas como «static constexpr» en funciones declaradas como constexpr.
• Funciones implementadas definidas en el futuro estándar C2x C:
• Se agregó soporte para cargar múltiples archivos de configuración (los archivos de configuración predeterminados se cargan primero y luego los especificados mediante el indicador «–config=», que ahora se puede especificar varias veces).
• Se modificó el orden de carga de los archivos de configuración predeterminados: clang primero intenta cargar el archivo <triple>-<driver>.cfg y, si no lo encuentra, intenta cargar dos archivos <driver>.cfg y <triple>.cfg.
• Se agregó un nuevo indicador de compilación «-fcoro-aligned-allocation» para la distribución alineada de marcos de rutina.
• Se agregó el indicador «-fmodule-output» para habilitar el modelo de compilación monofásico de los módulos estándar de C++ .
• Se agregó el modo «-Rpass-analysis=stack-frame-layout» para diagnosticar problemas con el diseño del marco de pila.
• Se agregó un nuevo atributo __attribute__((target_version(«cpu_features»))) y se amplió la funcionalidad del atributo __attribute__((target_clones(«cpu_features1″,»cpu_features2»,…))) para seleccionar versiones específicas de funciones proporcionadas por la CPU AArch64 .
• Herramientas de diagnóstico mejoradas:
• Se agregó la advertencia «-Wsingle-bit-bitfield-constant-conversion» para detectar el truncamiento implícito al asignar uno a un campo de bits con signo de un bit.
• Diagnóstico extendido de variables constexpr no inicializadas.
• Se agregaron advertencias «-Wcast-function-type-strict» y «-Wincompatible-function-pointer-types-strict» para detectar posibles problemas al transmitir tipos de función.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/eU5rE2A
via IFTTT

Xen es un hipervisor que proporciona aislamiento seguro, control de recursos, garantías de calidad de servicio y migración de máquinas virtuales

Los desarrolladores de la plataforma XCP-ng, que se desarrolla bajo el ala del proyecto Xen, han publicado un plan para crear un reemplazo de Rust para varios componentes de la pila de software Xen.

El hipervisor Xen en sí aún no se va a procesar y el trabajo se centra principalmente en volver a trabajar los componentes individuales del conjunto de herramientas.

La plataforma actualmente usa componentes en C, Python, OCaml y Go, algunos de los cuales están desactualizados y causan problemas de mantenimiento. Se observa que el uso de Rust no conducirá a un aumento general en la cantidad de idiomas involucrados, ya que solo se implementa un componente en Go, que se planea reemplazar en primer lugar.

Obviamente, no espere que reescribamos el hipervisor Xen y todo en Rust como nuestro primer intento. De hecho, nuestro objetivo aquí es comenzar a reemplazar algunos componentes más pequeños a su alrededor, lo que nos permite «aumentar» el lenguaje en sí y pensar en cómo reemplazar las cosas bloque tras bloque, para toda la plataforma.

Rust se elige como un lenguaje que combina un alto rendimiento del código resultante con capacidades de memoria segura, no requiere el uso de un recolector de basura, es adecuado para desarrollar componentes de bajo y alto nivel, proporciona características adicionales para reducir el potencial errores, como el préstamo variable (borrow checker). Rust también está más extendido que el actual lenguaje XAPI OCaml, lo que facilitará la atracción de nuevos desarrolladores al proyecto.

En la primera etapa, se planea desarrollar reemplazos para varios componentes con el fin de resolver los procesos y preparar la base para reemplazar otras partes de la pila de software. En particular, en primer lugar, las herramientas de invitado de Linux se reescribirán en Rust, para el cual se usa actualmente el lenguaje Go, y el proceso en segundo plano para recopilar métricas, se escribirá en OCaml.

Dado que Rust es seguro y rápido, ¿qué más necesitamos? También necesitamos un lenguaje de programación que sea capaz de trabajar en varios niveles (inferior y superior en la pila). Yo no confiaría en Go o Python para hacer frente a cosas de tan bajo nivel que podemos tener en XCP-ng, y -de la misma manera- tampoco en C para hacer cosas de mayor nivel. El uso de Rust brinda el potencial de estar en todas partes en la pila XCP-ng’.

Además, Rust ya no es un lenguaje de «nicho». Por ejemplo, incluso si es excelente, OCaml (usado en XAPI) no se conoce lo suficiente, lo que reduce nuestras oportunidades de contratar fácilmente a personas con experiencia en este idioma. Esto también reduce la capacidad de una comunidad de código abierto para obtener colaboradores. Creemos que Rust no será un obstáculo para eso (tanto para la contratación como para las contribuciones), probablemente incluso lo contrario: un impulsor para atraer a más personas, ya que es una tecnología «deseada» .

La necesidad de rediseñar las herramientas de Linux guest tools (xe-guest-utilities) se debe a problemas de calidad de código y desarrollo fuera del Proyecto Xen bajo el control de Cloud Software Group, lo que dificulta el empaquetado y la influencia de la comunidad en el desarrollo. Se planea crear una nueva variante del conjunto de herramientas ( xen-guest-agent ) completamente desde cero, manteniéndolo lo más simple posible y separando la lógica del agente de las bibliotecas. Se decidió volver a trabajar en el proceso de fondo para recopilar métricas ( rrdd ), ya que es compacto y está separado, lo que facilita experimentar con el uso de un nuevo lenguaje durante el desarrollo.

El próximo año, probablemente se comenzará a trabajar en el desarrollo del componente xenopsd-ng en Rust, que nos permitirá optimizar la arquitectura de la pila de software. La idea principal es concentrar el trabajo con una API de bajo nivel en un componente y organizar la provisión de todas las API de alto nivel al resto de la pila a través de él.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/D5OmiqE
via IFTTT