Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

146
Views
¿Por qué __builtin_parity es opuesto?

Tanto GCC como Clang admiten una función definida por la implementación llamada __builtin_parity que ayuda a determinar la paridad de un número.

De acuerdo con lo que dice GCC :

Función integrada: int __builtin_parity (int x sin firmar)
Devuelve la paridad de x, es decir, el número de bits de 1 en x módulo 2.

Esto significa que si el número de bits 1 es par, devolverá 0 y 1 si es impar.

Lo mismo ocurre con Clang como lo probé en Compiler Explorer .

Sin embargo, el indicador de paridad real se establece cuando el número de bits establecidos es par.

¿Por que es esto entonces?

over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Son simplemente diferentes elecciones arbitrarias.

Primero tenga en cuenta que "el indicador de paridad real" es una función de hardware que solo se proporciona en algunas arquitecturas; de las arquitecturas actualmente en uso generalizado, creo que x86 es la única con tal bandera. Entonces, la existencia misma, y mucho menos la semántica exacta, de tal bandera, no es de ninguna manera un estándar universal.

Creo que la elección de GCC es más lógica: 0 y 1 deberían corresponder a par e impar respectivamente, porque 0 es un número par y 1 es impar. No sé por qué x86 y sus predecesores optaron por hacer lo contrario. Probablemente tendrías que viajar en el tiempo y preguntarle a los diseñadores.

De todos modos, el valor real de la bandera de paridad 8086 no es muy importante; los programadores normalmente lo probarían usando mnemónicos de ensamblador JPE y JPO , que le permiten especificar "saltar si la paridad es par" o "saltar si la paridad es impar" sin tener que recordar cuál corresponde a un bit 0 o 1 en la bandera. El valor solo sería relevante si quisiera inspeccionar el bit en el registro FLAGS a través PUSHF o LAHF , lo que sería útil solo en circunstancias muy oscuras.

Miré un poco la historia. El Intel 8086 copió sus banderas del 8080, que hace lo mismo. Su predecesor, el 8008, también tenía un "flip-flop" de paridad, que al parecer estaba configurado en paridad uniforme, pero no está claro porque solo podía saltar condicionalmente sobre el estado del flip-flop, no realmente leerlo. Se dice que el 8008 se derivó del Datapoint 2200, que en realidad documenta su cambio de paridad de la manera opuesta: configurado para impar, reiniciado para par. Pero la semántica 80xx podría haber sido un detalle de implementación interna sin ningún significado profundo, como que el circuito de paridad simplemente produjo el resultado de esa manera, y no se molestaron en agregar otra puerta NOT para invertirlo. Cualquier investigación adicional probablemente sea más sobre el tema de Retrocomputing.SE.

El indicador de paridad x86 es solo marginalmente útil para __builtin_parity() de GCC de todos modos, porque solo prueba un byte. Se puede usar para un valor mayor al unir sus bytes, y GCC/clang hará esto si no hay otra opción. Maneja el sentido inverso de la bandera usando setnp en lugar de setp al final (un programador humano simplemente habría escrito setpo y no tendría que pensar en el valor set/clear de la bandera).

Sin embargo, casi todas las CPU x86 de los últimos 10 años admiten la instrucción popcnt , y GCC/clang usará esto en su lugar si está disponible (y luego simplemente extraiga el bit bajo).

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!