Je plussoie vigoureusement !
J'ai parfois l'impression que tout le monde ici code des bases de données relationelles en J2EE sur des serveurs virtualisés ...
Mais l'informatique embarquée est un des domaines où notre pingouin préféré a une très forte progression, et bouscule pas mal le marché établi.
Pourtant dans ce domaine, malgré la Loi de Moore, on continue à avoir des besoins de compacité, de faible consommation (donc de faible fréquence, et faible quantité de mémoire) incompatibles avec la "grosse" informatique. Mais avec des besoins de performance quand même importants ! Par exemple, tous les téléphones mobiles modernes sont des systèmes multiprocesseurs, avec 2 à 4 processeurs RISC et DSP ...
On se tourne alors vers des architectures spécifques, comme les DSP, qui présentent un rapport MIPS/Watt très intéressant.
Je rajouterais le chiffre suivant : RAM : 4Go --> 1Mo (code + données)
Vitesse : 2x2.7 GHz --> 720 MHz Consommation : 90W --> 0.9W
Mais indépendamment des questions de ressources plus spartiates en embarqué, il y a un domaine où on ne coupe pas à la gestion des bits un par un : c'est quand on est en contact direct avec le hardware. Pour écrire un bit précis dans un registre (sans faire un ràz des autres bits), et même souvent faire une opération read-test-modify-write qu'on aimerait bien non-interruptible, c'est tout simplement indispensable.
Une méthode pour cela est le "champ de bits", en fait une union entre une structure et la valeur globale du registre. On peut ainsi modifier indépendamment les champs de la structure, et lire/écrire la valeur complète dans le registre. Par contre, si on veut être portable il faut le définir deux fois : une fois en big endian, une fois en little endian.
Exemple approximatif en Little Endian :
typedef bitfield{
typedef union{
unsigned int register;
struct{
int field1 : 1; /* bit 0, LSB */
int field2 : 3; /* bits 1 à 3 */
int field3 : 4; /* bits 4 à 7 */
int nothing : 24; /* bits 8 à 31, MSB */
}bit
}
}
Ensuite, il y a aussi des parties particulières du code, comme les routines d'interruption ou le bootloader, pour lesquelles les contraintes sont telles qu'on échappe rarement à l'écriture de quelques instructions en assembleur.
[^] # Re: Bravo
Posté par Jimmy . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 5.
J'ai parfois l'impression que tout le monde ici code des bases de données relationelles en J2EE sur des serveurs virtualisés ...
Mais l'informatique embarquée est un des domaines où notre pingouin préféré a une très forte progression, et bouscule pas mal le marché établi.
Pourtant dans ce domaine, malgré la Loi de Moore, on continue à avoir des besoins de compacité, de faible consommation (donc de faible fréquence, et faible quantité de mémoire) incompatibles avec la "grosse" informatique. Mais avec des besoins de performance quand même importants ! Par exemple, tous les téléphones mobiles modernes sont des systèmes multiprocesseurs, avec 2 à 4 processeurs RISC et DSP ...
On se tourne alors vers des architectures spécifques, comme les DSP, qui présentent un rapport MIPS/Watt très intéressant.
Je rajouterais le chiffre suivant :
RAM : 4Go --> 1Mo (code + données)
Vitesse : 2x2.7 GHz --> 720 MHz
Consommation : 90W --> 0.9W
Mais indépendamment des questions de ressources plus spartiates en embarqué, il y a un domaine où on ne coupe pas à la gestion des bits un par un : c'est quand on est en contact direct avec le hardware. Pour écrire un bit précis dans un registre (sans faire un ràz des autres bits), et même souvent faire une opération read-test-modify-write qu'on aimerait bien non-interruptible, c'est tout simplement indispensable.
Une méthode pour cela est le "champ de bits", en fait une union entre une structure et la valeur globale du registre. On peut ainsi modifier indépendamment les champs de la structure, et lire/écrire la valeur complète dans le registre. Par contre, si on veut être portable il faut le définir deux fois : une fois en big endian, une fois en little endian.
Exemple approximatif en Little Endian :
Ensuite, il y a aussi des parties particulières du code, comme les routines d'interruption ou le bootloader, pour lesquelles les contraintes sont telles qu'on échappe rarement à l'écriture de quelques instructions en assembleur.