misc ideas

[davidgao]

we should probably always prefer cross-GCC even when not compiling for another platform. as we want standalone binaries, is autotools any good for our project? or do we write makefiles by hand? link against libgcc or not? hint: arm has no div or mod on its own, nor floating point operations, so we need some software implementation if we are to use them. btw, is libgcc safe for standalone application? i should get gcc5 and build a new toolchain. we should include documentation on how to build the desired toolchain, which can be TONS of problems for beginners...

[BarclayII]

autotools may look cool but we want to keep things simple. Unless we indeed would like to introduce autotools to the class, we probably have to write Makefiles manually. Floating point operations are not necessary in operating system design (I guess), so it may be better not to include libgcc. However ARM may have to deal with integer division or modulo, and I'm not sure how ARM solves this issue. Anyway, MIPS64 have hardware divider. MIPS also include built-in FPU, but I'm not going to use it. Building toolchain should not hinder development: the principle for selecting toolchain is to favor the easiest one first, where setting up the environment doesn't require much effort, and if possible, the latest. Fedora includes its own cross-gcc packages inside its repository and could be easily installed by yum since version 18, and Debian/Ubuntu should also have something alike. Not sure whether openSUSE includes such packages, though.

[davidgao]

let's ignore autotools. about integer division and modulo, as MIPS and X86 both have their hardware solution, ARM should possibly get a coprocessor working. Gcc will emit a call to libgcc's __aeabi_uidivmod and other functions when division and modulo is used in the code, so i should write my own library containing only the necessary functions instead. We can safely put libgcc away now. openSUSE does not include such packages so I built my own toolchain, but $PATH should cover that up.

[BarclayII]

One more suggestion about toolchain: may be we can pull existing packages from the Internet? Loongson have a tar.gz on their website which packed all the necessary programs, albeit of older versions. I wonder if Zedboard had ever published this kind of stuff.

[davidgao]

i think including their web address in our document is better. Zedboard ships with license of vivado, including its SDK, including toolchain (as standalone applications), however, their toolchains are pre-compiled and may not work well outside their environment. and about DIV() and MOD() macros, I think they are not good ideas. ARM's solution is included in the modified comment above, and this solution will not modify any existing code. another thought, ARM has a LOT of configurations, and need extra compiler flags to turn things (like thumb instructions, which may make a mess with interrupts) off explicitly. That means makefiles need platform-specific flags.

[BarclayII]

Downloaded a cross-gcc for arm and finally figured out how gcc play with divisions. There are a family of library functions like __aeabi_idiv, __aeabi_uidivmod or something alike, so we should probably implement all those functions, which is better to be put inside lib/libc/arch/arm. Quite an elegant solution. About platform-specific flags, assuming all the people are using GNU make, we can exploit conditionals:

ARCH = arm
CFLAGS_ARM = ...
CFLAGS_MIPS64 = ...
ifeq ($(ARCH), arm)
CFLAGS = $(CFLAGS_ARM)
else ifeq ($(ARCH), mips64)
CFLAGS = $(CFLAGS_MIPS64)
endif

(Note the indentation) Users can choose the architecture by specifying ARCH variable in command line:

make ARCH=mips64

[davidgao]

just perfect.