<div dir="ltr">Hi<div><br></div><div>After bouncing some email with Richard Earnshaw, I learned that ARMv8</div><div>support entails two parts:</div><div><br></div><div>+ additional instructions/FPUs in 32-bit support</div><div>+ new 64-bit mode</div><div><br></div><div>From a tools perspective, the new 64-bit mode is easy. It results in a a new </div><div>target named aarch64-rtems. I have posted patches to add that to binutils</div><div>and gcc.</div><div><br></div><div>The 32-bit mode additions are more complicated because they result in</div><div>the need for multilibs. I noticed that config/arm/t-elf in gcc does not include</div><div>v8 multilibs but config/arm/t-aprofile does. I did an experiment and swapped</div><div>our config/arm/t-rtems with config/arm/t-aprofile. The resulting multilib variants</div><div>are attached.</div><div><br></div><div>There were 12 before and 28 after. Six were new v8 so that explains some.</div><div>I didn't try to decipher or match up the rest.</div><div><br></div><div>I noticed we currently have "eb" which if indicative of big endian doesn't </div><div>match how the other arm targets handle big vs little endian. They use a</div><div>separate target to get big endian.</div><div><br></div><div>My (possibly faulty) recollection is that our gcc multilib variants are down </div><div>selected to only include exactly what we have BSPs for. On other targets, </div><div>we just use the same as the default elf/eabi toolchain. This always left</div><div>the tools foundation ready for any supported CPU model or BSP.</div><div><br></div><div>We should add ARMv8 multilibs to lay the groundwork for folks to add</div><div>BSPs to RTEMS.. Do we do it by switching from t-rtems to t-aprofile?</div><div><br></div><div>--joel</div></div>