Publicado hace 5 meses por salteado3 a elchapuzasinformatico.com

Cada vez aparecen más chips que usan el set de instrucciones RISC-V en vez de ARM o x86. Os contamos todos los secretos de esta ISA.

Comentarios

pawer13

Y USA está a punto de pegarse un tiro en el pie, queriendo evitar que empresas americanas usen y desarrollen esta ISA para evitar "ayudar" a China a mejorarla.
Al final el open source es el mejor ejemplo de libre mercado, ya que es imposible imponer cuotas o cerrar licencias

G

#10 Intel tampoco, pero EEUU si protege a Intel. Europa tirará dinero en su Eurochip, que no irá a ninguna parte. Pudo proteger a ARM.

e

#8 Creo que estas un poco despistado. Los desarrolladores de FOSS lo hacen por amor al arte, no para enriquecerse.
El FOSS está para que todo el mundo lo use. No tiene sentido hacer FOSS si luego nadie lo usa. La única restricción, que a veces se la saltan, es que si lo cambias, para adaptarlo o mejorarlo, debes compartirlo de la misma forma ( GPLv3).
Que haya empresas/gente que utiliza el FOSS ajeno para enriquecerse es una efecto colateral, que no es estrictamente malo.
Yo si hago FOSS es para que lo usen el máximo número de personas posible.
Si tu objetivo es enriquecerte haciendo sfw, igual el FOSS no es lo tuyo, mejor elije otro modelo.

x

#7 #12 Pertenece a SoftBank Group, japonesa.

spidey

#7 ARM no es libre.

menjaprunes

#2 RISC architecture is gonna change everything

e

#4 el open source está moribundo por culpa de todos los parásitos que la habitan.

Muchos que han hecho foss están cabreadisimos y abandonando sus proyectos porque los demás se pasan por el forro sus licencias y se enriquecen a su costa.

solo se encuentran con parásitos que quieren que sigas desarrollando por amor al arte.

l

#39 Es una serie de articulos, por si tienes interes en mas.

abnog

#40 Sí, ya lo ví. Gracias!

p

#2 sin una microarquitectura también libre esperemos que no salga de donde está.

meneandro

#13 GPL vale, porque promueve que se comparta lo que se desarrolle (y ahí va tanto funcionalidades como parches de seguridad; la calidad y el alcance del código sube y todos salen beneficiados) .

El problema que apunta #8 es debido a la moda de usar licencias que permiten hacer lo que quieras con los fuentes. De ahí si que hay muchísima gente que se aprovecha del trabajo de los demás sin que el resto se beneficie.

Por otro lado, nadie evita que alguien pueda cobrar o enriquecerse usando software libre; de hecho, la GPL permite y anima a cobrar por el trabajo que se realiza.

M

#21 Porque no son conscientes de los problemas de seguridad que pudiera dar (y que llegó a dar) un procesador totalmente propietario. Precisamente diría que es esta filosofía la que ha hecho nacer RISC-V, además de poder utilizar . De hecho, tanto para un usuario que no conozca nada de esto como sí tampoco debería importarle que sea Intel, AMD, ARM o este, siempre que exista software o pueda compilarlo él mismo.

https://ammitechnologies.com/arquitectura-risc-v/

RISC-V resulta además prometedor en cuanto a eficiencia energética por proceso.

kotomuss

Pero sorpresa, tras un set de instrucciones libre se necesita una implementación y diseño físico eficiente en silicio. Y adivinad, son las herramientas para hacerlo libres?

Pues no, así que suerte con la implementación y a ver si lográis hacerlo mejor que los especialistas que sí tienen acceso a ellas.

Lerena

#31 La Idea es que china y sus futuros procesadores lo saquen al mercado.

n

#6 Que no hay que pagar una licencia a nadie, te parece poco?

e

#15 #13 Licencias "absolutamente libres", con todas las consecuencias, como las MIT.
Cuando uno licencia sfw con una licencia "haz con esto lo que te salga del rabo", es normal que lo hagan.

D

#34 sí, para escribir un par de artículos científicos llenos de promesas y cumplir con la cuota de publicaciones que tu centro de investigación te impone.

D

#38 dejas de depender de Intel o ARM y pasas a depender de Altera (que es Intel) o Xilinx, y pagando mucho más.

sauron34_1

#2 pero si Risc-V tiene un porrón de años! No te digo que no vaya a cambiar nada en el futuro, pero tiempo ha tenido y por ahora, nada.

sauron34_1

#43 veremos entonces.

e

#13 hay todo tipo de motivos en el mundo open source para hacerlo. pero lo que está pasando es que empresas están cogiendo software libre y integrándolo en sus productos como propio

abnog

#22 Excelente artículo, muchas gracias.

sonix

Pues excepto por menor consumo, no se que ventajas puede tener sobre ARM por ejemplo.

p

#17 nada legal impide que mierdas sean mucho peores en risc-v y por nada es que los que están poniendo dinero precisamente es la característica que están vendiendo, modifico mi IP core para vendertela y hacer el sistema incompatible con otros clientes a los que les vendo mi IP, lo que viene a ser «configuracion y personalizacion».

C

#36 Más que "muchos", yo lo dejaría en "algunos". Y de los de uso diario para usuario de ofimática hay pocos.

Aokromes

#6 que eeuu o "la comunidad internacional" no te puede sancionar el usarlos.

p

#64 tú y el grueso de los consumidores quieren que sea así, quién fabrica puede querer lo contrario y pagar el desarrollo, sea propio o por una empresa externa como Sifive o Andes, para lo contrario. Por mucha filosofía que pongas el que paga manda, y si la clientela no va a castigar el caos de la incompatibilidad a propósito, ya que eso se premia en la obsolescencia, la evolución de compatibilidades a a ser peor que ARM.
Por eso openrisck, opensparck y otras que depende de una sociedad superior que es de arquitectura abierta aparte de una ISA abierta no se tocan.
Que hay núcleos y algunas arquitecturas abiertas en risc-v si, que Andes o Sifive tienen su arquitectura propia también.

p

#66 ISA no es arquitectura, ARM por lo menos tiene un penalización en precio y licencia para meter cosas a mayores fuera ARM.

La extensión si es la gestión de encendido para ahorro de energía del propio SoC o gestión de memoria, caso de Andes, significa que si no es el software propio tienes un ladrillo.
https://riscv.org/wp-content/uploads/2017/05/Tue0900-170509-AndeStarV5.pdf#page=20 En ese PDF te va quedar claro que van a querer hacer ese infierno a peor, es más barato generarlo que con ARM.

p

#66 Quien hace silicio no se ciñe al estándar: https://patchwork.kernel.org/project/linux-riscv/patch/20231122121235.827122-9-peterlin@andestech.com/
https://lwn.net/Articles/954941/

La cuestión es quien compra este silicio precisamente lo quiere por eso, y que el consumidor final del producto pase por el aro de estar atado a soporte de la empresa compradora del silicio, de hecho esto ya ha pasado: https://www.phoronix.com/news/Andes-Tech-NDS32-Removal

p

#69 lo importante es sacar todo el dinero que puedas del comprador, lo otro está en tu cabeza.

En SOC si la extensión es no quiere que ningún SO sin firmar por la empresa pueda leer o escribir la RAM tienes un ladrillo, lo mismo que apagar o encender núcleos, un SOC de 40 núcleos pequeños y 16 grandes pueden dejarlo limitado a solo un núcleo pequeño o la GPU en algo con pantalla integrada.
Alguna empresa sacará algo ceñido al estándar para que pueda funcionar con sistemas libres para evitar desarrollar software, otras van a optar por multiplicar las barreras a límites con X86 o ARM no podían.

danip3

Curioso porque probablemente en el futuro lo utilicen empresas europeas y probablemente copiando a los chinos que son quienes lo están desarrolando lol

#7 Británica

D

#33 no hablemos de OpenOffice, que es incapaz de pegar una imagen sin joderte todo el layout.

D

#44 tienes decenas de fabricantes de arquitecturas ARM o Intel para ser independiente de ARM o Intel. Incluso tienes microprocesadores y microcontroladores de otras arquitecturas, sin necesidad de usar una FPGA.

e

#52 Eso es otra guerra, que también.
Además viendo como evoluciona la cosa, a lo que se tiende no es a compraras un software o licencia de uso sino a contrataras un servicio que está disponible online.

meneandro

#52 Son cosas diferentes y atacan ámbitos diferentes. MS y otras han tenido que asociarse para permitir usar patentes en desarrollos de software libre porque se dieron cuenta de que estaban pisándose su propia prosperidad con eso (dado que las compañías propietarias hacen mucho dinero con el software libre y demandarse unas a otras por cosas que usan todas al final era una tontería).

meneandro

#20 ¿Y de qué van las mejores prestaciones? ¿de ocultarlas bajo las soluciones de siempre (añadir cosas que aceleren otras cosas por hardware y optimizar el software propio para exprimirlas, aunque el rendimiento con el software de terceros apeste hasta que les sueltes pasta o les convenzas de que optimicen específicamente para ti) y pagar más para tener mejores tecnologías de fabricación para poder luego decir que su solución es mejor que la de los demás? ¿como lo de presumir que las arquitecturas ARM son mejores y consumen menos cuando se fabrican en los mejores nodos de fabricación y con técnicas de fabricación específicas para lograr poco consumo porque su nicho de mercado es el móvil, servidores flojitos pero con "high core count" y como mucho portátiles pero que escalan horriblemente mal?

Te voy a poner un ejemplo: ¿Sabes quién fue la primera arquitectura que apostó por muchísimos cores ligeros y poco potentes para atacar el mercado de los servidores web y java? la sun SPARC (en particular, a partir del UltraSparc T2 -8 cores con 8 hilos cada uno, hasta 64 threads simultáneas- y T3 -16 cores con 16 hilos cada uno, 128 hilos, que se dice pronto-) . Y tuvo relativo éxito, pero al final el mercado buscaba cosas más generalistas y potentes y murió. ¿Sabes qué otra arquitectura intentó algo similar? bulldozer de amd. Y falló en parte por estar fabricados con tecnología que intel podía barrer tranquilamente (aunque con gran capacidad multitarea, poco potentes y consumiendo más que los procesadores de intel). Y ojo, que hablamos de la tecnología que movió la play4.

Justamente ahora AMD tiene soluciones que aunan todo y por eso están comiéndose ciertos mercados: tienen cpus con gran cantidad de capacidad multiproceso, con muchísima potencia cada núcleo individual y con un consumo contenidísimo y mucho menor que el de los productos de sus rivales en sus mismas gamas y tecnologías de fabricación equivalentes (si, incluso comparados con apple... sácalos de productos específicamente optimizados para ninguna arquitectura y verás que el consumo para hacer las mismas tareas está equilibrado o incluso es menor en la solución de amd). Y quitando apple, el resto de soluciones arm que han tratado de competir, no han podido (ya sea por compatibilidad/software, porque el rendimiento sin ser malo no podía compararse, etc). Del mismo modo, Intel también tiene soluciones que compiten de tú a tú con el resto en determinadas condiciones o para determinado software (optimizado).

Está claro que el problema es definir correctamente qué prestaciones necesitas y en qué entornos te mueves (soluciones de refrigeración púramente pasivas y limitadores de voltaje, etc. existen también en el mundo x86).

Volviendo al tema Risc-V, ya hay disponibles numerosas placas de desarrollo de dispositivos Risc-V, muchas más para probar cosas y desarrollar mientras se ponen al mercado productos realmente competitivos de nueva generación. Aún no ha salido un producto que sea killer usando RiscV, pero si hay alternativas relativamente competitivas respecto de algunos productos. Y RiscV tiene un importante papel en sitios donde menos pensarías. Por ejemplo, las gráficas NVIDIA tienen un controlador RISCV integrado desde 2016 que se encarga de hacer cosas que antes hacían los drivers por software, descargándolos y permitiendo bajar las latencias de ciertos procesos internos. Igualmente, todo es cuestión de pasta, se avanza más rápido cuanta más pasta tengas (que se lo pregunten a apple, por ejemplo, la pasta que se deja en desarrollar procesadores que sólo usan ellos, incluso comparada con la que se dejan fabricantes que venden y licencian sus procesadores a terceros, donde se juegan sus ingresos). A RiscV la apoyan empresas más bien emergentes (comparados con los monstruos que son los apple, qualcomm, intel, amd... y los fabricantes chinos). Y aún así, no están tan lejos en ciertas cosas comparados con "las grandes arquitecturas" y cada vez atraen más atención y recursos.

meneandro

#19 Pero un chip RiscV debe funcionar en todos lados, otra cosa es que uses esas mierdas o las ignores. RiscV no es ARM (que licencia y olvida), la filosofía es "comparte la base tal cual, estándar y sin tocar y funcionarás en todos lados; y las mierdas que quieras añadir por tu lado, irán por separado". ¿Recuerdas que habían ordenadores pentium soportando mmx y otros que no? pues el software o aprovechaba mmx o no, pero todo seguía funcionando (más o menos lento, pero funcionaba). Con ARM esto no es así, tienes que compilar con compiladores diferentes y generar código diferente, a veces tan sustancialmente diferente que no funciona en los dispositivos ARM de la competencia o en los tuyos propios de meses atrás, las diferencias llegan a esos extremos.

meneandro

#65 ¿Entiendes lo que he dicho? da igual las extensiones que añadan los fabricantes, son extensiones opcionales u optativas, la base funciona igual y un kernel de linux para riscv arrancará en cualquiera, así que puedes usarlos aunque no explotes todas sus características, igual que se hace con un x86. ¿Que el fabricante de turno podrá hacer lo que le de la gana igualmente? por supuesto. Pero sería tirarse piedras contra su propio tejado y perder soporte oficial de linux. ¿Que x86 no es la mejor arquitectura con la que compararse, teniendo en cuenta que el código de arranque se sus procesadores tiene muchísima tela que cortar? también, aunque la cosa mejorará mucho cuando el soporte a 32 bits sea eliminado más pronto que tarde en software, y quién sabe cuándo y quién dará el primer paso, en hardware.

Si no me crees a mi sobre lo de riscv, léete esto:
https://www.kernel.org/doc/html/v5.12/riscv/patch-acceptance.html

"Additionally, the RISC-V specification allows implementors to create their own custom extensions. These custom extensions aren’t required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we’ll only to accept patches for extensions that have been officially frozen or ratified by the RISC-V Foundation. (Implementors, may, of course, maintain their own Linux kernel trees containing code for any custom extensions that they wish.)"

Poder usar un kernel genérico para usar placas RiscV es una ventaja que muy pocos fabricantes pueden ignorar, saber que en el kernel sólo va a acabar lo que haya sido ratificado por la fundación o extensiones de terceros estables y probadas (como las extensiones de vulkan u opengl) y que cualquier fabricante podrá implementarlas si son útiles y necesarias también es un plus. Mantener tu propia rama de linux, drivers, etc. es lo que hace que ARM sea un caos y sea imposible mantener teléfonos actualizados y con soporte, siempre hay alguna pieza de la cadena que empieza a tener incompatibilidades o problemas con lo demás más pronto que tarde.


Compara con el infierno que es ARM, lleno de documentos de SOCs específicos e incompatibles entre si en mayor o menor medida:
https://www.kernel.org/doc/html/v5.12/arm/index.html

Al menos ARM64 está mejor organizado y saneado (de hecho, RiscV parte un poco de esto y lo mejora para su arquitectura):
https://www.kernel.org/doc/html/v5.12/arm64/index.html

meneandro

#68 De tu propio enlace:
"The Andes PMU extension provides the same mechanism as Sscofpmf, allowing us to reuse the SBI PMU driver to support event sampling and mode filtering."
¿qué más da que hagan extensiones propias? son extensiones, tú añades lo que quieras mientras la base sea la misma para todos. ¿Por qué te iban a pedir que no añadieras cosas? lo importante es que seas compatible a nivel de base, si otros fabricantes no soportan tus extensiones o no son estándar da igual. No aprovechas esas funcionalidades, pero todo sigue funcionando... no rompen nada.

"To make use of this custom PMU extension, "xandespmu" needs to be appended to the riscv,isa-extensions for each cpu node in device-tree, and enable CONFIG_ANDES_CUSTOM_PMU."

¿Y si no quieres usar esa extensión? ¡pues no la usas! no es imprescindible para tener un riscV corriendo, del mismo modo que no es imprescindible tener una de las nuevas extensiones de intel AMX para poder usar un kernel x86 en un amd... ¿necesitas soporte de intel en caso de que sus extensiones rompan? pues igual que cuando sus instrucciones de división fallaban en los pentium... ¿eso en qué afecta al resto de procesadores intel que no tienen esas extensiones o las de otros fabricantes? ¿impiden que amd pueda implementar las extensiones cuando le interese? pues eso...

meneandro

#67 ¿Pero tú entiendes el significado de la palabra extensión? ¿una cosa que es aparte del estándar y que puedes implementar o no? ¿quieres ir por favor a la ilustración de la página numerada como 25? ¿no lo ves en el dibujito, o incluso con un diagrama te pierdes?

RISC-V KERNEL -> Baseline -> Full feature y luego, fuera de todo esto "codesense, stacksafe, powerbrake, dsp/fp extensions, security extensions, custom extensions, etc."

Incluso vienen así puestas en conjuntos, para que veas y diferencies que hay capas que son superconjuntos de otras capas, y luego cosas en conjuntos completamente separados...

No ya es que ni leas tus propios enlaces... es que te lo ponen de la manera más sencilla posible y lo ignoras...

Pero es más, en la 27 dice literalmente:
Adopting RISC-V as Natural ISA Evolution: V5m+ more Andes Ext.
O sea, la v5m + extensiones de Andes

sonix

#17 yo hablo de mejores prestaciones no de filosofía tecnología

sonix

#14 lo de chip FPGA imagino que lo dicen porque es un procesador sencillo, pero a lo que iba, que mejora tiene sobre la competencia, porque lo que decis es prácticamente una filosofía que a la mayoría de mortales ni les interesa

sonix

#25 sigue sin ser una respuesta que le interese al usuario promedio

sonix

#30 no, sera mas barato si es algo con poco rendimiento

f

#33 Hay muchos programas libres que igualan o superan a sus competidores.

Quizá el Gimp no sea mejor que el Photoshop, pero pagando 12€ al mes... para mucha gente no es mejor producto el PS

f

#47 Seguramente más de los que crees. Y repito, muchas veces hay que considerar el precio del propietario. Photoshop está bien para profesionales. Quizá para aficionados avanzados también, pero hay que pensarse mucho pagar esa cantidad si no vas a facturar luego.

n

#26 al usuario promedio tampoco le importa tu opinión y aquí estás.

JandroPV

#48 y cuando no, también. Con el tiempo se ha visto que el software libre no es la solución sino un parche. La solución es luchar contra las patentes de software y dar la propiedad a quien la haya copiado de manera que se pueda hacer lo que les dé la gana con la copia.

JandroPV

#23 esa es la diferencia entre el open sours y el software libre: mientras que en uno les das carta abierta para que hagan lo que les plazca, en el segundo les obligas a compartir el código.

sonix

#51 pues seguro que le interesa menos la tuya y aquí sigues.

oprimide

#2 son arquitecturas con perspectiva de género

G

#2 ARM es una empresa europea, otra cosa es que europa no proteja sus activos.

MorrosDeNutria

Para los que quieran verlo en acción:
-


-


A mi la idea me gusta mucho, le tengo el ojo puesto a ver como evoluciona.

bass

#26 si se desarrolla va a ser mas barato hacer lo mismo. A ver si al usuario promedio le interesa el ahorro.

c

Veo Gimp y veo Photoshop y, diría aquél: "No es tontería, las tecnologías libres igualan a los competidores"

s

#29 Siempre se pueden usar FPGA para implementar los RISC-V que hagan falta, que no serán tan eficientes como un producto final pero seguro que nos sirve para salir del paso.

s

#35 Yo he ejecutado un linux en una placa fpga y aunque no le veo "futuro" ahora mismo es un gran avance no depender de un hardware especifico para ejecutar un software que te hagas tu mismo. ¿Que cualquier micro intel le dan mil patadas en rendimiento? Si, claro pero lo que se habla aquí es de libertad y no depender de nadie aunque es cierto que nos vamos para atrás un par de décadas si usamos eso.

kotomuss

#34 Pero de qué coño estás hablando? Me dices que en los sistemas embebidos o computación de propósito general de medio mundo vas a escalar tus aplicaciones con FPGAs? Te van a salir unas cifras de coste/PPA muy exitosas.

Baja un poco a la realidad.

s

#41 hay más fabricantes de fpga como lattice o gowin y no es una cuestión de dinero sino de no dependencia. El poder ejecutar x software en cualquier hardware sin depender del fabricante. Por ahí van los tiros.

s

#42 a ver creo que no has entendido mi comentario no hablo de coste sino de independencia a ejecutar un software en cualquier hardware. Ahora mismo hay en AliExpress placas corriendo risc-v con un Linux completo por menos que una rpi zero. Decía lo de las fpga por la independencia del fabricante, no estás atado a Intel o amd solamente.

bass

#32 no, siempre que se siga desarrollando y no se quede como algo residual, será más barato que su alternativa directa con pago por licencia.
Obviamente no van a empezar sacando procesadores que intenten rivalizar con los i9 o los m2 ultra. Pero si demuestran estar maduros, pronto se pueden empezar a ver en dispositivos poco potentes (se me ocurre un lector de tinta electronica por ejemplo) y de ahi ir escalando.

bass

#47 Valve y su proton estan demostrando que el problema no es el SO, bastantes juegos estan sacando mas rendimiento en linux que en windows, incluso teniendo que pasar por proton que aunque poco, algo de rendimiento se lleva.

Gimp es peor que ps, si. Pero el problema es que adobe no saca ps para linux. En video ahi tienes a davinci resolve arrasando y está a para todos los SO.

Los beneficios del software y el hardware libres son otros. Aunque queráis mirar a otro lado. Pixar trabaja con sus propias herramientas de soft libre sin pasar por windows o mac. Será que son tontos o no tienen dinero para pagar licencias.

kotomuss

#55 Tiene una obsesión con las FPGA. Al parecer no conoce otra cosa.

kotomuss

#45 lee #41 y #55 de nuevo