On Thu, Dec 15, 2005 at 02:35:54PM -0700, Kim Lux wrote: > What are the "<<23"s about ? [...] > C67_g((0 << 29) | //creg > (0 << 28) | //inv > (C67_map_regn(c) << 23) | //dst > (C67_map_regn(b) << 18) | //src2 (possible x path) > (C67_map_regn(a) << 13) | //src1 > (xpath << 12) | //x cross path if opposite sides > (0x7b << 5) | //opcode > (0x6 << 2) | //opcode fixed > (C67_map_regs(c) << 1) | //side of dest > (0 << 0)); //parallel
I don't know anything about C67, but this appears to be a simple bitfield packing function. I assume C67_map_regn(c) returns a 5-bit value in the range [0,31], which is then shifted 23 bits so that it ends up in bits 24-28 of the resulting machine word. > If one is writing a new assembler, should it be done in the same way ? That probably depends on the machine architecture. Each system will have its own special issues and requirements. C67 looks like a simple design with 32-bit instructions and not a lot of variation in the instruction formats. Other architectures are not so simple, for example: - i386 has variable-length instructions and (if you include support for later models) a gigantic instruction set. The instruction set manual for i686 fills something like two 700-page books. - SPARC has "delay slots" that can cause the instruction after a branch to be executed even when the branch is taken; this may require instructions to be emitted out-of-order. - Itanium2 requires instructions to be emitted in bundles: each 128 bits contains 3 41-bit instructions and one 5-bit template describing the execution units involved. This gets complicated and the compiler is responsible for scheduling access to the CPU's resources. -Dave Dodge _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel