-
Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the fluidsynth project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be simple, with a small amount of code related to the CPU architecture in the project. Is this assessment accurate? I look forward to your help and response. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Correct. There is a bit x87 FPU related code in the project, which is solely used for debugging purposes and not compiled by default (cf. cmake options I don't think there is any "porting" in terms of changing the source code necessary at all. You just need to compile fluidsynth for a different target architecture. When doing so, you need to make sure that the intrinsic integer types are of same width as for x86 by default. I.e.: char: 1 byte Not sure if we have any And you need to deal with fluidsynth's dependencies as well, esp. glib. |
Beta Was this translation helpful? Give feedback.
Correct. There is a bit x87 FPU related code in the project, which is solely used for debugging purposes and not compiled by default (cf. cmake options
enable-fpe-check
andenable-trap-on-fpe
).I don't think there is any "porting" in terms of changing the source code necessary at all. You just need to compile fluidsynth for a different target architecture. When doing so, you need to make sure that the intrinsic integer types are of same width as for x86 by default. I.e.:
char: 1 byte
short: 2 bytes
int: 4 bytes
…