On 11/09/2020 12:08, Karel Gardas wrote:
On 9/11/20 11:40 AM, Sebastian Huber wrote:
If I'm not mistaken, then this is simply fixed by using other BSP's
variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
and gcc's lib provides necessary synchronization functions then...
The question is if there are RTEMS users in this universe which have x64
hardware in use which understands only the pc486/pc586/pc686 instruction
sets. This is stuff from the 1990s.
OK! So first uarch from 2000s is NetBurts and later core. Would you like
to stop on that? Honestly I'm a bit confused since if you are talking
about obsoleting '90s then we're in amd64 territory and then the
question is if to keep 32bit BSP or go straight to 64bit. Unfortunately
amd64 BSP provides just clock and console IIRC and and in comparison
with that pc386 supports a lot more features (VESA fb, libbsd)...
Or do you propose to just add more BSP variants to pc386 to support
optimization/isns generation for more modern CPUs and deprecate older
variants?
I don't know. I think we should somehow figure out which x86 hardware is
in use by RTEMS users.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
