Skip to first unread message
martin ribelotta
Apr 24, 2016, 5:27:06 PM4/24/16
to embeb...@googlegroups.com
Gente, estuve mirando un poquito el ISA de esta nueva arquitectura RISC-V:
http://riscv.org/
Creada en berkeley igual que todas las cosas que destrullen el cerebro
(como el LSD)
Mi idea es ponerme a implementarla en VHDL (primero para aprender y
luego para aprender, porque es un ejercicio de masturbación nada mas)
Ahora, mi duda no es de como implementarlo o no, sino mas conceptual.
Mirando el ISA en si, me di cuenta, que las instrucciones que
realmente operan sobre los datos son pocas, siendo mayormente,
instrucciones de control, movimiento de registros, de carga y
almacenamiento, de comparación y saldo (ok, eso se puede entender como
operación sobre los datos)
Así que me pregunté, cual era el ratio de instrucciones en un programa
típico, es decir, cuantas instrucciones en un programa son usadas para
las operaciones en si, y cuantas para el control, movimiento de datos,
manejo de flujo del programa.
Hice una primera búsqueda en internet por papers sobre eso, pero
(decidía mía) no salio nada en los primeros resultados y me puse a
hacer yo mismo (tal vez con poco rigor científico)
La idea es dividir las instrucciones que se ejecutan en "utiles" (que
operan sobre datos en si) e "inutiles" o "innocuas" a los datos (que
no los transforman)
Ejemplo de instrucciones utiles: add, cmp, xor, sub, mul, div, etc.
Ejemplo de instrucciones inutiles: mov, ld, st, b.*, bl, blx, etc.
Aclaro que no me rompí demasiado, agarre un par de algoritmos como
fft/firs y un OS completo (chibiOS) y le mande un objdump junto con un
grep para cada conjunto de instrucciones.
El target objetivo es un procesador típico como el cortex-m4, el
compilador es gcc 5.0 y todo se hace en -O2 (algo típico del software
actual)
Estoy masticando mas algoritmos así que todavía no pongo muchos
resultados pero en ChibiOS da 70% de instrucciones "inútiles" y el
resto de "las otras" (no diferencio mucho, por eso podría decirse que
son "al menos 70%)
FFT: 91%
IFF: 60%
FIR: 68%
Esto me hace plantear que estamos haciendo no algo mal, sino TODO mal.
Es decir, armamos un ISA-X con un gran repertorio de instrucciones
(sea RISC, CISC o lo que sea) y la mayoría están destinadas a "no
hacer nada" por la causa que es "masticar datos"
Luego los compiladores usan mas del 50% de las instrucciones en "nada
de nada" (siempre visto desde el punto de vista de transformar datos)
para que el resto del programa recién empiece a hacer su trabajo.
Como estoy seguro que los métodos que estoy usando están
fundamentalmente mal (objdump|grep no es lo mas científico que se
puede hacer) y que solo estoy centrándome en una arquitectura dada,
consulto por acá si alguien sabe algo de este tema o ha leído alguna
cosa al respecto.
Mi planteo es, de comprobar esto, que estamos haciéndolo TODO MAL,
desde que el $%$#%#$#$ de Von Newman planteo su arquitectura de
buses!!!! Y hardvard es la misma M$%#A!!!!
Ok, no estoy diciendo nada que no sepa cualquier desarrollador de DSP
sobre VHDL o cualquiera que haya implementado un RTL para algun
procesamiento dado.
¿Que onda las arquitecturas en GPU? Resuelven esta limitación o es
algo demasiado acotado para ser de propósito general (a pesar del
nombre GPGPU) ¿O cuando se hacen de propósito general termina cayendo
en el mismo poso de Von Newman?
Nada, eventualmente sacare mas números, pero espero que alguien en la
lista tenga idea de estudios sobre esto que me eviten seguir perdiendo
el domingo y poder dormir sin soñar con pipelines raros...
Saludos!
http://riscv.org/
Creada en berkeley igual que todas las cosas que destrullen el cerebro
(como el LSD)
Mi idea es ponerme a implementarla en VHDL (primero para aprender y
luego para aprender, porque es un ejercicio de masturbación nada mas)
Ahora, mi duda no es de como implementarlo o no, sino mas conceptual.
Mirando el ISA en si, me di cuenta, que las instrucciones que
realmente operan sobre los datos son pocas, siendo mayormente,
instrucciones de control, movimiento de registros, de carga y
almacenamiento, de comparación y saldo (ok, eso se puede entender como
operación sobre los datos)
Así que me pregunté, cual era el ratio de instrucciones en un programa
típico, es decir, cuantas instrucciones en un programa son usadas para
las operaciones en si, y cuantas para el control, movimiento de datos,
manejo de flujo del programa.
Hice una primera búsqueda en internet por papers sobre eso, pero
(decidía mía) no salio nada en los primeros resultados y me puse a
hacer yo mismo (tal vez con poco rigor científico)
La idea es dividir las instrucciones que se ejecutan en "utiles" (que
operan sobre datos en si) e "inutiles" o "innocuas" a los datos (que
no los transforman)
Ejemplo de instrucciones utiles: add, cmp, xor, sub, mul, div, etc.
Ejemplo de instrucciones inutiles: mov, ld, st, b.*, bl, blx, etc.
Aclaro que no me rompí demasiado, agarre un par de algoritmos como
fft/firs y un OS completo (chibiOS) y le mande un objdump junto con un
grep para cada conjunto de instrucciones.
El target objetivo es un procesador típico como el cortex-m4, el
compilador es gcc 5.0 y todo se hace en -O2 (algo típico del software
actual)
Estoy masticando mas algoritmos así que todavía no pongo muchos
resultados pero en ChibiOS da 70% de instrucciones "inútiles" y el
resto de "las otras" (no diferencio mucho, por eso podría decirse que
son "al menos 70%)
FFT: 91%
IFF: 60%
FIR: 68%
Esto me hace plantear que estamos haciendo no algo mal, sino TODO mal.
Es decir, armamos un ISA-X con un gran repertorio de instrucciones
(sea RISC, CISC o lo que sea) y la mayoría están destinadas a "no
hacer nada" por la causa que es "masticar datos"
Luego los compiladores usan mas del 50% de las instrucciones en "nada
de nada" (siempre visto desde el punto de vista de transformar datos)
para que el resto del programa recién empiece a hacer su trabajo.
Como estoy seguro que los métodos que estoy usando están
fundamentalmente mal (objdump|grep no es lo mas científico que se
puede hacer) y que solo estoy centrándome en una arquitectura dada,
consulto por acá si alguien sabe algo de este tema o ha leído alguna
cosa al respecto.
Mi planteo es, de comprobar esto, que estamos haciéndolo TODO MAL,
desde que el $%$#%#$#$ de Von Newman planteo su arquitectura de
buses!!!! Y hardvard es la misma M$%#A!!!!
Ok, no estoy diciendo nada que no sepa cualquier desarrollador de DSP
sobre VHDL o cualquiera que haya implementado un RTL para algun
procesamiento dado.
¿Que onda las arquitecturas en GPU? Resuelven esta limitación o es
algo demasiado acotado para ser de propósito general (a pesar del
nombre GPGPU) ¿O cuando se hacen de propósito general termina cayendo
en el mismo poso de Von Newman?
Nada, eventualmente sacare mas números, pero espero que alguien en la
lista tenga idea de estudios sobre esto que me eviten seguir perdiendo
el domingo y poder dormir sin soñar con pipelines raros...
Saludos!
Guillermo Villamayor
Apr 24, 2016, 5:44:22 PM4/24/16
to embeb...@googlegroups.com
Martín yo miraría en un algoritmo típico cuantas operaciones son para
transformar datos y cuantas para moverlos. Por otro lado el hecho de que
halla muchas instrucciones para mover datos puede ser un tema de comodidad,
para que sea mas fácil utilizarlas. Pensá que las operaciones que puede
hacer un micro nativamente no son tantas y los movimientos en un sistema
complejo si pueden ser muchos. De todas formas es una observación
interesante.
-----Mensaje original-----
From: martin ribelotta
Sent: Sunday, April 24, 2016 6:26 PM
To: embeb...@googlegroups.com
Subject: [embeb32] Duda existencial
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google
Embebidos32. Para postear en este grupo, escribe un email a
embeb...@googlegroups.com. Para des-suscribirte, envía un email a
embebidos32...@googlegroups.com. Para más opciones, visita el sitio
del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes,
envía un correo electrónico a embebidos32...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
transformar datos y cuantas para moverlos. Por otro lado el hecho de que
halla muchas instrucciones para mover datos puede ser un tema de comodidad,
para que sea mas fácil utilizarlas. Pensá que las operaciones que puede
hacer un micro nativamente no son tantas y los movimientos en un sistema
complejo si pueden ser muchos. De todas formas es una observación
interesante.
-----Mensaje original-----
From: martin ribelotta
Sent: Sunday, April 24, 2016 6:26 PM
To: embeb...@googlegroups.com
Subject: [embeb32] Duda existencial
-- Recibiste este mensaje porque estás suscripto al Grupo Google
Embebidos32. Para postear en este grupo, escribe un email a
embeb...@googlegroups.com. Para des-suscribirte, envía un email a
embebidos32...@googlegroups.com. Para más opciones, visita el sitio
del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes,
envía un correo electrónico a embebidos32...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.
Fernando Lichtschein
Apr 24, 2016, 6:09:02 PM4/24/16
to embebidos32@
Martín,
Admiro tus ganas de hacerte problemas....
Creo que el mix depende de la aplicación, las que tienen algo que ver con lo administrativo y lo humano van a mover datos más que otra cosa. En la vida real pasa lo mismo, mis compañeros que se dedican al "management" se la pasan en reuniones y escribiendo memos y dicen que eso es útil, supongo que con los sistemas debe pasar lo mismo. Ahora si una aplicación procesa señales de audio, video, radar o lo que sea el cómputo puede llegar a tener preponderancia sobre el movimiento de datos, pero hasta ahí nomás. Una aplicación que resuelva caminos en redes, procese imágenes o que utilice métodos de elementos finitos maneja muuucha información en matrices dispersas (las imágenes no estoy tan seguro, pero son muchos datos) y ése aspecto es muy importante, por más que sea mover datos.
Por otro lado se me sale el docente/padre/adulto de adentro, es "destruyen" y "halla" (del verbo haber).
Saludos y que puedas encontrar respuestas a tus dudas
Marcelo Navarta
Apr 24, 2016, 6:46:07 PM4/24/16
to embeb...@googlegroups.com
Fernando, apoyo la docencia en la forma de expresión escrita. Si me permitís y con todo respeto, obviamente, del verbo haber es "haya" , y "halla" cuando el verbo es hallar (encontrar). Ejemplos: Espero que no se HAYA destruido. El se HALLA desesperado por su situación. Respecto a lo técnico comparto tus conceptos. Abrazo.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Fernando Lichtschein
Apr 24, 2016, 8:01:49 PM4/24/16
to embebidos32@
Marcelo,
La expresión en particular fue "Por otro lado el hecho de que halla muchas instrucciones" que es del verbo haber, por lo tanto es "haya".
Saludos,
Christian N
Apr 25, 2016, 9:10:12 AM4/25/16
to Embebidos32
Hay que tener en cuenta que la transferencia de datos es inveitable en cada llamada a funcion ya que el preambulo y la salida generan la ventana de almacenamiento. Esto sesga en cierta manera la estadistica debido a la ABI. Lo mismo ocurre con las interrupciones, los cambios de contexto y todo aquello que requiera tener datos especificos de un proceso...
Mira (tal ves ya lo leiste)
https://www.strchr.com/x86_machine_code_statistics
https://news.ycombinator.com/item?id=9762062
En breve me fijo si puedo pasarte por aca un paper... ;-/
Mira (tal ves ya lo leiste)
https://www.strchr.com/x86_machine_code_statistics
https://news.ycombinator.com/item?id=9762062
En breve me fijo si puedo pasarte por aca un paper... ;-/
Gerardo Puga
Apr 25, 2016, 9:42:30 AM4/25/16
to embeb...@googlegroups.com
Martín,
Dale una mirada al libro "Compute Architecture: A Quantitative Approach" de Hennessy y Patterson (los fundadores del paradigma RISC).En ese libro tenés todos los análisis guían el diseño de una ISA (arquitectura del set de intrucciones), estadísticas de mezcla de instrucciones a partir de programas "tipo" para diferentes aplicaciones, cómo medir la performance y cómo definirla según el contexto (spoiler: no es la cantidad de instrucciones lo más importante), y análisis comparados de los ISAs de diferentes procesadores, incluyendo vectoriales, SIMD, GPU, y otros artefactos ya de museo.
En el sitio del libro podés ver el índice, algunos apéndices en pdf para descargar y un capítulo o dos de muestra.
http://booksite.elsevier.com/9780123838728/index.php
El libro está en todas las bibliotecas universitarias porque es un libro clásico en los cursos de grado de Arquitectura de Procesadores.
Tomas M
Apr 25, 2016, 9:57:06 AM4/25/16
to embeb...@googlegroups.com
Tengo el libro, el cual puedo donarte martin ya que te interesaste en el tema. Es exelente.
Nada mas triste que un libro juntando polvo.Avisame si te interesa.
Saludos
Tomas
Para acceder a más opciones, visita https://groups.google.com/d/optout.
martin ribelotta
Apr 25, 2016, 10:27:58 AM4/25/16
to embeb...@googlegroups.com
El día 25 de abril de 2016, 10:42, Gerardo Puga <glp...@gmail.com> escribió:
> Martín,
>
> Dale una mirada al libro "Compute Architecture: A Quantitative Approach" de
> Hennessy y Patterson (los fundadores del paradigma RISC).
>
Yeap si, conozco el libro, lo he leido para varias asignaturas y
> Martín,
>
> Dale una mirada al libro "Compute Architecture: A Quantitative Approach" de
> Hennessy y Patterson (los fundadores del paradigma RISC).
>
varios trabajos (siempre en los puntos que necesitaba, no es que fuera
mi lectura cuando voy al baño)
> En ese libro tenés todos los análisis guían el diseño de una ISA
> (arquitectura del set de intrucciones), estadísticas de mezcla de
> instrucciones a partir de programas "tipo" para diferentes aplicaciones,
> cómo medir la performance y cómo definirla según el contexto (spoiler: no es
> la cantidad de instrucciones lo más importante), y análisis comparados de
> los ISAs de diferentes procesadores, incluyendo vectoriales, SIMD, GPU, y
> otros artefactos ya de museo.
>
Es cierto que lo que yo describi mas arriba no indica performance,
pero tampoco estaba buscando definir eso, sino "eficiencia"
En realidad, para medir performance, deberia hacerse un profile de las
instrucciones que ejecuta el procesador para un algoritmo determinado.
Igual, la eficiencia que yo quiero medir, es la cantidad de trabajo
"no relacionado con la operación en si" que el procesador realiza.
Es decir, cuanto desperdicia el procesador por el simple hecho de "ser
procesador general"
martin ribelotta
Apr 25, 2016, 10:37:37 AM4/25/16
to embeb...@googlegroups.com
El día 25 de abril de 2016, 10:10, Christian N <cneg...@gmail.com> escribió:
> Hay que tener en cuenta que la transferencia de datos es inveitable en cada
> llamada a funcion ya que el preambulo y la salida generan la ventana de
> almacenamiento. Esto sesga en cierta manera la estadistica debido a la ABI.
> Lo mismo ocurre con las interrupciones, los cambios de contexto y todo
> aquello que requiera tener datos especificos de un proceso...
>
Eso suponiendo que tenemos un ABI, un contexto y un procesador "tradicional".
> Hay que tener en cuenta que la transferencia de datos es inveitable en cada
> llamada a funcion ya que el preambulo y la salida generan la ventana de
> almacenamiento. Esto sesga en cierta manera la estadistica debido a la ABI.
> Lo mismo ocurre con las interrupciones, los cambios de contexto y todo
> aquello que requiera tener datos especificos de un proceso...
>
Si te pones a ver como se hacen las cosas en el procesamiento de
señales sobre FPGA, todo eso es irrelevante.
El punto que busco, es ver cuanto de "logística" necesita un
procesador de propósito general y cuanto es realmente la operación en
si.
Como bien dicen mas arriba, esto no es medición de la "performance" en
si, ya que son muchos los factores que pueden determinarla.
Peeeero:
- Si yo tengo que ejecutar 100 instrucciones, para realizar 10
operaciones, tengo una eficiencia del 10%. (es un ejemplo, no esta
basado en nada real)
- Si en un CPU dado, las 90 instrucciones "inútiles" se ejecutan en 10
ciclos (por ser superescalar y todo eso) mientras que las otras 10
tardan 30 ciclos, entonces mis instrucciones "inútiles" impactan menos
en la performance.
- Pero tuve que gastar energía, silicio y tiempo en decodificar,
encausar y ejecutar 90 instrucciones que "no aportan" al objetivo de
ser del procesador.
> Mira (tal ves ya lo leiste)
> https://www.strchr.com/x86_machine_code_statistics
> https://news.ycombinator.com/item?id=9762062
>
> En breve me fijo si puedo pasarte por aca un paper... ;-/
>
modo" en el ISA thumb2 (definitivamente, una arquitectura LOAD/STORE
necesita mas "logística" para funcionar)
Agustin Bonelli
Apr 25, 2016, 11:17:40 AM4/25/16
to embeb...@googlegroups.com
Buenas,
Aporto mi granito de arena a la discusion:
Martin, segun pude interpretar de tus email, lo que estas considerando como util o inutil es si la operacion es de transofrmar algun dato en otro, o si es moverlo de aca para alla. Bien, teniendo en cuenta eso, creo que toda arquitectura Load/store va a dar ineficiente segun ese criterio, porque las operaciones de la ALU solo operan sobre registros (por favor corriganme si digo una gansada los que saben mas de procesadores).
Ahora bien, se podria repensar toda la arquitectura y no hacer el load store, y tener instrucciones que operen directamente con la memoria, pero me imagino que seguro va a haber delays y retardos por que va a seguir habiendo cache miss, y toda la historia. Yo trabaje un poco con DSP, y lo que vi es que para reducir esta carga de la que hablas, inventaron el DMA, que para procesamiento de señales es obligatorio, y todos los DSP lo tienen (y ARM y MIPS y todo el mundo tambien). En los DSP, en general, ademas del DMA se hicieron otras cosas para mejorar esa performance como Zero overhead loops, VLWI, SIMD, adressing mode circular para la FFT, y un par de cositas mas. Pero en ningun caso tiene que ver con repensar todo el modelo de la arquitectura.
Saludos,
Agustin
________________________________________
From: embeb...@googlegroups.com <embeb...@googlegroups.com> on behalf of martin ribelotta <martinr...@gmail.com>
Sent: Monday, April 25, 2016 11:37 AM
To: embeb...@googlegroups.com
Subject: Re: [embeb32] Re: Duda existencial
Para obtener más opciones, visita https://groups.google.com/d/optout.
Aporto mi granito de arena a la discusion:
Martin, segun pude interpretar de tus email, lo que estas considerando como util o inutil es si la operacion es de transofrmar algun dato en otro, o si es moverlo de aca para alla. Bien, teniendo en cuenta eso, creo que toda arquitectura Load/store va a dar ineficiente segun ese criterio, porque las operaciones de la ALU solo operan sobre registros (por favor corriganme si digo una gansada los que saben mas de procesadores).
Ahora bien, se podria repensar toda la arquitectura y no hacer el load store, y tener instrucciones que operen directamente con la memoria, pero me imagino que seguro va a haber delays y retardos por que va a seguir habiendo cache miss, y toda la historia. Yo trabaje un poco con DSP, y lo que vi es que para reducir esta carga de la que hablas, inventaron el DMA, que para procesamiento de señales es obligatorio, y todos los DSP lo tienen (y ARM y MIPS y todo el mundo tambien). En los DSP, en general, ademas del DMA se hicieron otras cosas para mejorar esa performance como Zero overhead loops, VLWI, SIMD, adressing mode circular para la FFT, y un par de cositas mas. Pero en ningun caso tiene que ver con repensar todo el modelo de la arquitectura.
Saludos,
Agustin
________________________________________
From: embeb...@googlegroups.com <embeb...@googlegroups.com> on behalf of martin ribelotta <martinr...@gmail.com>
Sent: Monday, April 25, 2016 11:37 AM
To: embeb...@googlegroups.com
Subject: Re: [embeb32] Re: Duda existencial
Nicolás Majorel Padilla
Apr 25, 2016, 2:50:31 PM4/25/16
to Embebidos32
Hola, voy a aportar alguna opinión.
En general, la mezcla de instrucciones es fuertemente dependiente del programa en sí, como ya dijeron. De todos modos, mezclas típicas (para una arquitectura de tipo Load/Store) muestran alrededor de un 40-50% de instrucciones de procesamiento de datos, que vendrían a ser las definidas como "útiles", dejando el resto para las "inútiles" (transferencias de datos y control).
Sí, pienso que la culpa de ello es el tipo de arquitectura, pero que no es un problema muy crítico. Y sí, pienso que la culpa en el fondo es de Von Neumann :-P Hay mucha secuencialidad en todos los códigos escritos, y hay poco aprovechamiento de paralelismo.
Ahora, en la actualidad hay gente trabajando sobre este asunto, así no sos el único que no pudo dormir a las noches pensando cosas por el estilo. Si están curiosos, les dejo tres nuevas arquitecturas para que investiguen: la más avanzada (e interesante para mí) es The Mill (https://millcomputing.com/docs/), otro es TOMI Celeste (http://www.venraytechnology.com/home.htm) y el último es el Automata Processor (http://www.micronautomata.com/). Que los disfruten!
Saludos.
En general, la mezcla de instrucciones es fuertemente dependiente del programa en sí, como ya dijeron. De todos modos, mezclas típicas (para una arquitectura de tipo Load/Store) muestran alrededor de un 40-50% de instrucciones de procesamiento de datos, que vendrían a ser las definidas como "útiles", dejando el resto para las "inútiles" (transferencias de datos y control).
Sí, pienso que la culpa de ello es el tipo de arquitectura, pero que no es un problema muy crítico. Y sí, pienso que la culpa en el fondo es de Von Neumann :-P Hay mucha secuencialidad en todos los códigos escritos, y hay poco aprovechamiento de paralelismo.
Ahora, en la actualidad hay gente trabajando sobre este asunto, así no sos el único que no pudo dormir a las noches pensando cosas por el estilo. Si están curiosos, les dejo tres nuevas arquitecturas para que investiguen: la más avanzada (e interesante para mí) es The Mill (https://millcomputing.com/docs/), otro es TOMI Celeste (http://www.venraytechnology.com/home.htm) y el último es el Automata Processor (http://www.micronautomata.com/). Que los disfruten!
Saludos.
Fernando Lichtschein
Apr 25, 2016, 2:58:58 PM4/25/16
to embebidos32@
Lo gracioso es que cuando empezaron con los microprocesadores (yo enganché cuando salieron el 8080 y el 6800, mi primer micro fue un 8085) cada vez que salìa uno nuevo tenia más instrucciones y eso supuestamente era mejor, hasta que aparecieron los RISC y "cambió el paradigma". Las primeras arquitecturas eran load/store, no lo decían así pero las instrucciones operaban sobre el acumulador o sobre el acumulador y un registro. Después salieron micros en los que los operandos podían estar en memoria (en los PIC es fácil por que en realidad la RAM es realmente un montón de registros), y ahora lo moderno es load/store. Lo del paralelismo es nuevo, me parece que llegaron a un techo en cuanto a frecuencia de clock (un poco más de 3 GHz) y la capacidad de procesamiento se aumenta agregando núcleos.
Saludos,
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages