This document describes techniques for writing compiler backends that convert the LLVM Intermediate Representation (IR) to code for a specified machine or other languages. Code intended for a specific machine can take the form of either assembly code or binary code (usable for a JIT compiler).
The backend of LLVM features a target-independent code generator that may create output for several types of target CPUs — including X86, PowerPC, ARM, and SPARC. The backend may also be used to generate code targeted at SPUs of the Cell processor or GPUs to support the execution of compute kernels.
The document focuses on existing examples found in subdirectories of llvm/lib/Target in a downloaded LLVM release. In particular, this document focuses on the example of creating a static compiler (one that emits text assembly) for a SPARC target, because SPARC has fairly standard characteristics, such as a RISC instruction set and straightforward calling conventions.
The audience for this document is anyone who needs to write an LLVM backend to generate code for a specific hardware or software target.
These essential documents must be read before reading this document:
To follow the SPARC examples in this document, have a copy of The SPARC Architecture Manual, Version 8 for reference. For details about the ARM instruction set, refer to the ARM Architecture Reference Manual. For more about the GNU Assembler format (GAS), see Using As, especially for the assembly printer. Using As contains a list of target machine dependent features.
To write a compiler backend for LLVM that converts the LLVM IR to code for a specified target (machine or other language), follow these steps:
In the .cpp and .h. files, initially stub up these methods and then implement them later. Initially, you may not know which private members that the class will need and which components will need to be subclassed.
To actually create your compiler backend, you need to create and modify a few files. The absolute minimum is discussed here. But to actually use the LLVM target-independent code generator, you must perform the steps described in the LLVM Target-Independent Code Generator document.
First, you should create a subdirectory under lib/Target to hold all the files related to your target. If your target is called "Dummy," create the directory lib/Target/Dummy.
In this new directory, create a Makefile. It is easiest to copy a Makefile of another target and modify it. It should at least contain the LEVEL, LIBRARYNAME and TARGET variables, and then include $(LEVEL)/Makefile.common. The library can be named LLVMDummy (for example, see the MIPS target). Alternatively, you can split the library into LLVMDummyCodeGen and LLVMDummyAsmPrinter, the latter of which should be implemented in a subdirectory below lib/Target/Dummy (for example, see the PowerPC target).
Note that these two naming schemes are hardcoded into llvm-config. Using any other naming scheme will confuse llvm-config and produce a lot of (seemingly unrelated) linker errors when linking llc.
To make your target actually do something, you need to implement a subclass of TargetMachine. This implementation should typically be in the file lib/Target/DummyTargetMachine.cpp, but any file in the lib/Target directory will be built and should work. To use LLVM's target independent code generator, you should do what all current machine backends do: create a subclass of LLVMTargetMachine. (To create a target from scratch, create a subclass of TargetMachine.)
To get LLVM to actually build and link your target, you need to add it to the TARGETS_TO_BUILD variable. To do this, you modify the configure script to know about your target when parsing the --enable-targets option. Search the configure script for TARGETS_TO_BUILD, add your target to the lists there (some creativity required), and then reconfigure. Alternatively, you can change autotools/configure.ac and regenerate configure by running ./autoconf/AutoRegen.sh.
LLVMTargetMachine is designed as a base class for targets implemented with the LLVM target-independent code generator. The LLVMTargetMachine class should be specialized by a concrete target class that implements the various virtual methods. LLVMTargetMachine is defined as a subclass of TargetMachine in include/llvm/Target/TargetMachine.h. The TargetMachine class implementation (TargetMachine.cpp) also processes numerous command-line options.
To create a concrete target-specific subclass of LLVMTargetMachine, start by copying an existing TargetMachine class and header. You should name the files that you create to reflect your specific target. For instance, for the SPARC target, name the files SparcTargetMachine.h and SparcTargetMachine.cpp.
For a target machine XXX, the implementation of XXXTargetMachine must have access methods to obtain objects that represent target components. These methods are named get*Info, and are intended to obtain the instruction set (getInstrInfo), register set (getRegisterInfo), stack frame layout (getFrameInfo), and similar information. XXXTargetMachine must also implement the getTargetData method to access an object with target-specific data characteristics, such as data type size and alignment requirements.
For instance, for the SPARC target, the header file SparcTargetMachine.h declares prototypes for several get*Info and getTargetData methods that simply return a class member.
namespace llvm { class Module; class SparcTargetMachine : public LLVMTargetMachine { const TargetData DataLayout; // Calculates type size & alignment SparcSubtarget Subtarget; SparcInstrInfo InstrInfo; TargetFrameInfo FrameInfo; protected: virtual const TargetAsmInfo *createTargetAsmInfo() const; public: SparcTargetMachine(const Module &M, const std::string &FS); virtual const SparcInstrInfo *getInstrInfo() const {return &InstrInfo; } virtual const TargetFrameInfo *getFrameInfo() const {return &FrameInfo; } virtual const TargetSubtarget *getSubtargetImpl() const{return &Subtarget; } virtual const TargetRegisterInfo *getRegisterInfo() const { return &InstrInfo.getRegisterInfo(); } virtual const TargetData *getTargetData() const { return &DataLayout; } static unsigned getModuleMatchQuality(const Module &M); // Pass Pipeline Configuration virtual bool addInstSelector(PassManagerBase &PM, bool Fast); virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast); }; } // end namespace llvm
For some targets, you also need to support the following methods:
In addition, the XXXTargetMachine constructor should specify a TargetDescription string that determines the data layout for the target machine, including characteristics such as pointer size, alignment, and endianness. For example, the constructor for SparcTargetMachine contains the following:
SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &FS) : DataLayout("E-p:32:32-f128:128:128"), Subtarget(M, FS), InstrInfo(Subtarget), FrameInfo(TargetFrameInfo::StackGrowsDown, 8, 0) { }
Hyphens separate portions of the TargetDescription string.
You must also register your target with the TargetRegistry, which is what other LLVM tools use to be able to lookup and use your target at runtime. The TargetRegistry can be used directly, but for most targets there are helper templates which should take care of the work for you.
All targets should declare a global Target object which is used to represent the target during registration. Then, in the target's TargetInfo library, the target should define that object and use the RegisterTarget template to register the target. For example, the Sparc registration code looks like this:
Target llvm::TheSparcTarget; extern "C" void LLVMInitializeSparcTargetInfo() { RegisterTarget<Triple::sparc, /*HasJIT=*/false> X(TheSparcTarget, "sparc", "Sparc"); }
This allows the TargetRegistry to look up the target by name or by target triple. In addition, most targets will also register additional features which are available in separate libraries. These registration steps are separate, because some clients may wish to only link in some parts of the target -- the JIT code generator does not require the use of the assembler printer, for example. Here is an example of registering the Sparc assembly printer:
extern "C" void LLVMInitializeSparcAsmPrinter() { RegisterAsmPrinter<SparcAsmPrinter> X(TheSparcTarget); }
For more information, see "llvm/Target/TargetRegistry.h".
You should describe a concrete target-specific class that represents the register file of a target machine. This class is called XXXRegisterInfo (where XXX identifies the target) and represents the class register file data that is used for register allocation. It also describes the interactions between registers.
You also need to define register classes to categorize related registers. A register class should be added for groups of registers that are all treated the same way for some instruction. Typical examples are register classes for integer, floating-point, or vector registers. A register allocator allows an instruction to use any register in a specified register class to perform the instruction in a similar manner. Register classes allocate virtual registers to instructions from these sets, and register classes let the target-independent register allocator automatically choose the actual registers.
Much of the code for registers, including register definition, register aliases, and register classes, is generated by TableGen from XXXRegisterInfo.td input files and placed in XXXGenRegisterInfo.h.inc and XXXGenRegisterInfo.inc output files. Some of the code in the implementation of XXXRegisterInfo requires hand-coding.
The XXXRegisterInfo.td file typically starts with register definitions for a target machine. The Register class (specified in Target.td) is used to define an object for each register. The specified string n becomes the Name of the register. The basic Register object does not have any subregisters and does not specify any aliases.
class Register<string n> { string Namespace = ""; string AsmName = n; string Name = n; int SpillSize = 0; int SpillAlignment = 0; list<Register> Aliases = []; list<Register> SubRegs = []; list<int> DwarfNumbers = []; }
For example, in the X86RegisterInfo.td file, there are register definitions that utilize the Register class, such as:
def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
This defines the register AL and assigns it values (with DwarfRegNum) that are used by gcc, gdb, or a debug information writer to identify a register. For register AL, DwarfRegNum takes an array of 3 values representing 3 different modes: the first element is for X86-64, the second for exception handling (EH) on X86-32, and the third is generic. -1 is a special Dwarf number that indicates the gcc number is undefined, and -2 indicates the register number is invalid for this mode.
From the previously described line in the X86RegisterInfo.td file, TableGen generates this code in the X86GenRegisterInfo.inc file:
static const unsigned GR8[] = { X86::AL, ... }; const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 }; const TargetRegisterDesc RegisterDescriptors[] = { ... { "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...
From the register info file, TableGen generates a TargetRegisterDesc object for each register. TargetRegisterDesc is defined in include/llvm/Target/TargetRegisterInfo.h with the following fields:
struct TargetRegisterDesc { const char *AsmName; // Assembly language name for the register const char *Name; // Printable name for the reg (for debugging) const unsigned *AliasSet; // Register Alias Set const unsigned *SubRegs; // Sub-register set const unsigned *ImmSubRegs; // Immediate sub-register set const unsigned *SuperRegs; // Super-register set };
TableGen uses the entire target description file (.td) to determine text names for the register (in the AsmName and Name fields of TargetRegisterDesc) and the relationships of other registers to the defined register (in the other TargetRegisterDesc fields). In this example, other definitions establish the registers "AX", "EAX", and "RAX" as aliases for one another, so TableGen generates a null-terminated array (AL_AliasSet) for this register alias set.
The Register class is commonly used as a base class for more complex classes. In Target.td, the Register class is the base for the RegisterWithSubRegs class that is used to define registers that need to specify subregisters in the SubRegs list, as shown here:
class RegisterWithSubRegs<string n, list<Register> subregs> : Register<n> { let SubRegs = subregs; }
In SparcRegisterInfo.td, additional register classes are defined for SPARC: a Register subclass, SparcReg, and further subclasses: Ri, Rf, and Rd. SPARC registers are identified by 5-bit ID numbers, which is a feature common to these subclasses. Note the use of 'let' expressions to override values that are initially defined in a superclass (such as SubRegs field in the Rd class).
class SparcReg<string n> : Register<n> { field bits<5> Num; let Namespace = "SP"; } // Ri - 32-bit integer registers class Ri<bits<5> num, string n> : SparcReg<n> { let Num = num; } // Rf - 32-bit floating-point registers class Rf<bits<5> num, string n> : SparcReg<n> { let Num = num; } // Rd - Slots in the FP register file for 64-bit floating-point values. class Rd<bits<5> num, string n, list<Register> subregs> : SparcReg<n> { let Num = num; let SubRegs = subregs; }
In the SparcRegisterInfo.td file, there are register definitions that utilize these subclasses of Register, such as:
def G0 : Ri< 0, "G0">, DwarfRegNum<[0]>; def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>; ... def F0 : Rf< 0, "F0">, DwarfRegNum<[32]>; def F1 : Rf< 1, "F1">, DwarfRegNum<[33]>; ... def D0 : Rd< 0, "F0", [F0, F1]>, DwarfRegNum<[32]>; def D1 : Rd< 2, "F2", [F2, F3]>, DwarfRegNum<[34]>;
The last two registers shown above (D0 and D1) are double-precision floating-point registers that are aliases for pairs of single-precision floating-point sub-registers. In addition to aliases, the sub-register and super-register relationships of the defined register are in fields of a register's TargetRegisterDesc.
The RegisterClass class (specified in Target.td) is used to define an object that represents a group of related registers and also defines the default allocation order of the registers. A target description file XXXRegisterInfo.td that uses Target.td can construct register classes using the following class:
class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, dag regList> { string Namespace = namespace; list<ValueType> RegTypes = regTypes; int Size = 0; // spill size, in bits; zero lets tblgen pick the size int Alignment = alignment; // CopyCost is the cost of copying a value between two registers // default value 1 means a single instruction // A negative value means copying is extremely expensive or impossible int CopyCost = 1; dag MemberList = regList; // for register classes that are subregisters of this class list<RegisterClass> SubRegClassList = []; code MethodProtos = [{}]; // to insert arbitrary code code MethodBodies = [{}]; }
To define a RegisterClass, use the following 4 arguments:
In SparcRegisterInfo.td, three RegisterClass objects are defined: FPRegs, DFPRegs, and IntRegs. For all three register classes, the first argument defines the namespace with the string 'SP'. FPRegs defines a group of 32 single-precision floating-point registers (F0 to F31); DFPRegs defines a group of 16 double-precision registers (D0-D15).
// F0, F1, F2, ..., F31 def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>; def DFPRegs : RegisterClass<"SP", [f64], 64, (add D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15)>; def IntRegs : RegisterClass<"SP", [i32], 32, (add L0, L1, L2, L3, L4, L5, L6, L7, I0, I1, I2, I3, I4, I5, O0, O1, O2, O3, O4, O5, O7, G1, // Non-allocatable regs: G2, G3, G4, O6, // stack ptr I6, // frame ptr I7, // return address G0, // constant zero G5, G6, G7 // reserved for kernel )>;
Using SparcRegisterInfo.td with TableGen generates several output files that are intended for inclusion in other source code that you write. SparcRegisterInfo.td generates SparcGenRegisterInfo.h.inc, which should be included in the header file for the implementation of the SPARC register implementation that you write (SparcRegisterInfo.h). In SparcGenRegisterInfo.h.inc a new structure is defined called SparcGenRegisterInfo that uses TargetRegisterInfo as its base. It also specifies types, based upon the defined register classes: DFPRegsClass, FPRegsClass, and IntRegsClass.
SparcRegisterInfo.td also generates SparcGenRegisterInfo.inc, which is included at the bottom of SparcRegisterInfo.cpp, the SPARC register implementation. The code below shows only the generated integer registers and associated register classes. The order of registers in IntRegs reflects the order in the definition of IntRegs in the target description file.
// IntRegs Register Class... static const unsigned IntRegs[] = { SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5, SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3, SP::I4, SP::I5, SP::O0, SP::O1, SP::O2, SP::O3, SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3, SP::G4, SP::O6, SP::I6, SP::I7, SP::G0, SP::G5, SP::G6, SP::G7, }; // IntRegsVTs Register Class Value Types... static const MVT::ValueType IntRegsVTs[] = { MVT::i32, MVT::Other }; namespace SP { // Register class instances DFPRegsClass DFPRegsRegClass; FPRegsClass FPRegsRegClass; IntRegsClass IntRegsRegClass; ... // IntRegs Sub-register Classess... static const TargetRegisterClass* const IntRegsSubRegClasses [] = { NULL }; ... // IntRegs Super-register Classess... static const TargetRegisterClass* const IntRegsSuperRegClasses [] = { NULL }; ... // IntRegs Register Class sub-classes... static const TargetRegisterClass* const IntRegsSubclasses [] = { NULL }; ... // IntRegs Register Class super-classes... static const TargetRegisterClass* const IntRegsSuperclasses [] = { NULL }; IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID, IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses, IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {} }
The register allocators will avoid using reserved registers, and callee saved registers are not used until all the volatile registers have been used. That is usually good enough, but in some cases it may be necessary to provide custom allocation orders.
The final step is to hand code portions of XXXRegisterInfo, which implements the interface described in TargetRegisterInfo.h. These functions return 0, NULL, or false, unless overridden. Here is a list of functions that are overridden for the SPARC implementation in SparcRegisterInfo.cpp:
During the early stages of code generation, the LLVM IR code is converted to a SelectionDAG with nodes that are instances of the SDNode class containing target instructions. An SDNode has an opcode, operands, type requirements, and operation properties. For example, is an operation commutative, does an operation load from memory. The various operation node types are described in the include/llvm/CodeGen/SelectionDAGNodes.h file (values of the NodeType enum in the ISD namespace).
TableGen uses the following target description (.td) input files to generate much of the code for instruction definition:
There is also a target-specific XXX.td file, where XXX is the name of the target. The XXX.td file includes the other .td input files, but its contents are only directly important for subtargets.
You should describe a concrete target-specific class XXXInstrInfo that represents machine instructions supported by a target machine. XXXInstrInfo contains an array of XXXInstrDescriptor objects, each of which describes one instruction. An instruction descriptor defines:
The Instruction class (defined in Target.td) is mostly used as a base for more complex instruction classes.
class Instruction { string Namespace = ""; dag OutOperandList; // An dag containing the MI def operand list. dag InOperandList; // An dag containing the MI use operand list. string AsmString = ""; // The .s format to print the instruction with. list<dag> Pattern; // Set to the DAG pattern for this instruction list<Register> Uses = []; list<Register> Defs = []; list<Predicate> Predicates = []; // predicates turned into isel match code ... remainder not shown for space ... }
A SelectionDAG node (SDNode) should contain an object representing a target-specific instruction that is defined in XXXInstrInfo.td. The instruction objects should represent instructions from the architecture manual of the target machine (such as the SPARC Architecture Manual for the SPARC target).
A single instruction from the architecture manual is often modeled as multiple target instructions, depending upon its operands. For example, a manual might describe an add instruction that takes a register or an immediate operand. An LLVM target could model this with two instructions named ADDri and ADDrr.
You should define a class for each instruction category and define each opcode as a subclass of the category with appropriate parameters such as the fixed binary encoding of opcodes and extended opcodes. You should map the register bits to the bits of the instruction in which they are encoded (for the JIT). Also you should specify how the instruction should be printed when the automatic assembly printer is used.
As is described in the SPARC Architecture Manual, Version 8, there are three major 32-bit formats for instructions. Format 1 is only for the CALL instruction. Format 2 is for branch on condition codes and SETHI (set high bits of a register) instructions. Format 3 is for other instructions.
Each of these formats has corresponding classes in SparcInstrFormat.td. InstSP is a base class for other instruction classes. Additional base classes are specified for more precise formats: for example in SparcInstrFormat.td, F2_1 is for SETHI, and F2_2 is for branches. There are three other base classes: F3_1 for register/register operations, F3_2 for register/immediate operations, and F3_3 for floating-point operations. SparcInstrInfo.td also adds the base class Pseudo for synthetic SPARC instructions.
SparcInstrInfo.td largely consists of operand and instruction definitions for the SPARC target. In SparcInstrInfo.td, the following target description file entry, LDrr, defines the Load Integer instruction for a Word (the LD SPARC opcode) from a memory address to a register. The first parameter, the value 3 (112), is the operation value for this category of operation. The second parameter (0000002) is the specific operation value for LD/Load Word. The third parameter is the output destination, which is a register operand and defined in the Register target description file (IntRegs).
def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr), "ld [$addr], $dst", [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
The fourth parameter is the input source, which uses the address operand MEMrr that is defined earlier in SparcInstrInfo.td:
def MEMrr : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops IntRegs, IntRegs); }
The fifth parameter is a string that is used by the assembly printer and can be left as an empty string until the assembly printer interface is implemented. The sixth and final parameter is the pattern used to match the instruction during the SelectionDAG Select Phase described in (The LLVM Target-Independent Code Generator). This parameter is detailed in the next section, Instruction Selector.
Instruction class definitions are not overloaded for different operand types, so separate versions of instructions are needed for register, memory, or immediate value operands. For example, to perform a Load Integer instruction for a Word from an immediate operand to a register, the following instruction class is defined:
def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), "ld [$addr], $dst", [(set IntRegs:$dst, (load ADDRri:$addr))]>;
Writing these definitions for so many similar instructions can involve a lot of cut and paste. In td files, the multiclass directive enables the creation of templates to define several instruction classes at once (using the defm directive). For example in SparcInstrInfo.td, the multiclass pattern F3_12 is defined to create 2 instruction classes each time F3_12 is invoked:
multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> { def rr : F3_1 <2, Op3Val, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), !strconcat(OpcStr, " $b, $c, $dst"), [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>; def ri : F3_2 <2, Op3Val, (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c), !strconcat(OpcStr, " $b, $c, $dst"), [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>; }
So when the defm directive is used for the XOR and ADD instructions, as seen below, it creates four instruction objects: XORrr, XORri, ADDrr, and ADDri.
defm XOR : F3_12<"xor", 0b000011, xor>; defm ADD : F3_12<"add", 0b000000, add>;
SparcInstrInfo.td also includes definitions for condition codes that are referenced by branch instructions. The following definitions in SparcInstrInfo.td indicate the bit location of the SPARC condition code. For example, the 10th bit represents the 'greater than' condition for integers, and the 22nd bit represents the 'greater than' condition for floats.
def ICC_NE : ICC_VAL< 9>; // Not Equal def ICC_E : ICC_VAL< 1>; // Equal def ICC_G : ICC_VAL<10>; // Greater ... def FCC_U : FCC_VAL<23>; // Unordered def FCC_G : FCC_VAL<22>; // Greater def FCC_UG : FCC_VAL<21>; // Unordered or Greater ...
(Note that Sparc.h also defines enums that correspond to the same SPARC condition codes. Care must be taken to ensure the values in Sparc.h correspond to the values in SparcInstrInfo.td. I.e., SPCC::ICC_NE = 9, SPCC::FCC_U = 23 and so on.)
The code generator backend maps instruction operands to fields in the instruction. Operands are assigned to unbound fields in the instruction in the order they are defined. Fields are bound when they are assigned a value. For example, the Sparc target defines the XNORrr instruction as a F3_1 format instruction having three operands.
def XNORrr : F3_1<2, 0b000111, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), "xnor $b, $c, $dst", [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>;
The instruction templates in SparcInstrFormats.td show the base class for F3_1 is InstSP.
class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { field bits<32> Inst; let Namespace = "SP"; bits<2> op; let Inst{31-30} = op; dag OutOperandList = outs; dag InOperandList = ins; let AsmString = asmstr; let Pattern = pattern; }
InstSP leaves the op field unbound.
class F3<dag outs, dag ins, string asmstr, list<dag> pattern> : InstSP<outs, ins, asmstr, pattern> { bits<5> rd; bits<6> op3; bits<5> rs1; let op{1} = 1; // Op = 2 or 3 let Inst{29-25} = rd; let Inst{24-19} = op3; let Inst{18-14} = rs1; }
F3 binds the op field and defines the rd, op3, and rs1 fields. F3 format instructions will bind the operands rd, op3, and rs1 fields.
class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins, string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> { bits<8> asi = 0; // asi not currently used bits<5> rs2; let op = opVal; let op3 = op3val; let Inst{13} = 0; // i field = 0 let Inst{12-5} = asi; // address space identifier let Inst{4-0} = rs2; }
F3_1 binds the op3 field and defines the rs2 fields. F3_1 format instructions will bind the operands to the rd, rs1, and rs2 fields. This results in the XNORrr instruction binding $dst, $b, and $c operands to the rd, rs1, and rs2 fields respectively.
The final step is to hand code portions of XXXInstrInfo, which implements the interface described in TargetInstrInfo.h. These functions return 0 or a Boolean or they assert, unless overridden. Here's a list of functions that are overridden for the SPARC implementation in SparcInstrInfo.cpp:
Performance can be improved by combining instructions or by eliminating instructions that are never reached. The AnalyzeBranch method in XXXInstrInfo may be implemented to examine conditional instructions and remove unnecessary instructions. AnalyzeBranch looks at the end of a machine basic block (MBB) for opportunities for improvement, such as branch folding and if conversion. The BranchFolder and IfConverter machine function passes (see the source files BranchFolding.cpp and IfConversion.cpp in the lib/CodeGen directory) call AnalyzeBranch to improve the control flow graph that represents the instructions.
Several implementations of AnalyzeBranch (for ARM, Alpha, and X86) can be examined as models for your own AnalyzeBranch implementation. Since SPARC does not implement a useful AnalyzeBranch, the ARM target implementation is shown below.
AnalyzeBranch returns a Boolean value and takes four parameters:
In the simplest case, if a block ends without a branch, then it falls through to the successor block. No destination blocks are specified for either TBB or FBB, so both parameters return NULL. The start of the AnalyzeBranch (see code below for the ARM target) shows the function parameters and the code for the simplest case.
bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB, MachineBasicBlock *&TBB, MachineBasicBlock *&FBB, std::vector<MachineOperand> &Cond) const { MachineBasicBlock::iterator I = MBB.end(); if (I == MBB.begin() || !isUnpredicatedTerminator(--I)) return false;
If a block ends with a single unconditional branch instruction, then AnalyzeBranch (shown below) should return the destination of that branch in the TBB parameter.
if (LastOpc == ARM::B || LastOpc == ARM::tB) { TBB = LastInst->getOperand(0).getMBB(); return false; }
If a block ends with two unconditional branches, then the second branch is never reached. In that situation, as shown below, remove the last branch instruction and return the penultimate branch in the TBB parameter.
if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) && (LastOpc == ARM::B || LastOpc == ARM::tB)) { TBB = SecondLastInst->getOperand(0).getMBB(); I = LastInst; I->eraseFromParent(); return false; }
A block may end with a single conditional branch instruction that falls through to successor block if the condition evaluates to false. In that case, AnalyzeBranch (shown below) should return the destination of that conditional branch in the TBB parameter and a list of operands in the Cond parameter to evaluate the condition.
if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) { // Block ends with fall-through condbranch. TBB = LastInst->getOperand(0).getMBB(); Cond.push_back(LastInst->getOperand(1)); Cond.push_back(LastInst->getOperand(2)); return false; }
If a block ends with both a conditional branch and an ensuing unconditional branch, then AnalyzeBranch (shown below) should return the conditional branch destination (assuming it corresponds to a conditional evaluation of 'true') in the TBB parameter and the unconditional branch destination in the FBB (corresponding to a conditional evaluation of 'false'). A list of operands to evaluate the condition should be returned in the Cond parameter.
unsigned SecondLastOpc = SecondLastInst->getOpcode(); if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) || (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) { TBB = SecondLastInst->getOperand(0).getMBB(); Cond.push_back(SecondLastInst->getOperand(1)); Cond.push_back(SecondLastInst->getOperand(2)); FBB = LastInst->getOperand(0).getMBB(); return false; }
For the last two cases (ending with a single conditional branch or ending with one conditional and one unconditional branch), the operands returned in the Cond parameter can be passed to methods of other instructions to create new branches or perform other operations. An implementation of AnalyzeBranch requires the helper methods RemoveBranch and InsertBranch to manage subsequent operations.
AnalyzeBranch should return false indicating success in most circumstances. AnalyzeBranch should only return true when the method is stumped about what to do, for example, if a block has three terminating branches. AnalyzeBranch may return true if it encounters a terminator it cannot handle, such as an indirect branch.
LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes of the SelectionDAG ideally represent native target instructions. During code generation, instruction selection passes are performed to convert non-native DAG instructions into native target-specific instructions. The pass described in XXXISelDAGToDAG.cpp is used to match patterns and perform DAG-to-DAG instruction selection. Optionally, a pass may be defined (in XXXBranchSelector.cpp) to perform similar DAG-to-DAG operations for branch instructions. Later, the code in XXXISelLowering.cpp replaces or removes operations and data types not supported natively (legalizes) in a SelectionDAG.
TableGen generates code for instruction selection using the following target description input files:
The implementation of an instruction selection pass must include a header that declares the FunctionPass class or a subclass of FunctionPass. In XXXTargetMachine.cpp, a Pass Manager (PM) should add each instruction selection pass into the queue of passes to run.
The LLVM static compiler (llc) is an excellent tool for visualizing the contents of DAGs. To display the SelectionDAG before or after specific processing phases, use the command line options for llc, described at SelectionDAG Instruction Selection Process.
To describe instruction selector behavior, you should add patterns for lowering LLVM code into a SelectionDAG as the last parameter of the instruction definitions in XXXInstrInfo.td. For example, in SparcInstrInfo.td, this entry defines a register store operation, and the last parameter describes a pattern with the store DAG operator.
def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src), "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
ADDRrr is a memory mode that is also defined in SparcInstrInfo.td:
def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
The definition of ADDRrr refers to SelectADDRrr, which is a function defined in an implementation of the Instructor Selector (such as SparcISelDAGToDAG.cpp).
In lib/Target/TargetSelectionDAG.td, the DAG operator for store is defined below:
def store : PatFrag<(ops node:$val, node:$ptr), (st node:$val, node:$ptr), [{ if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N)) return !ST->isTruncatingStore() && ST->getAddressingMode() == ISD::UNINDEXED; return false; }]>;
XXXInstrInfo.td also generates (in XXXGenDAGISel.inc) the SelectCode method that is used to call the appropriate processing method for an instruction. In this example, SelectCode calls Select_ISD_STORE for the ISD::STORE opcode.
SDNode *SelectCode(SDValue N) { ... MVT::ValueType NVT = N.getNode()->getValueType(0); switch (N.getOpcode()) { case ISD::STORE: { switch (NVT) { default: return Select_ISD_STORE(N); break; } break; } ...
The pattern for STrr is matched, so elsewhere in XXXGenDAGISel.inc, code for STrr is created for Select_ISD_STORE. The Emit_22 method is also generated in XXXGenDAGISel.inc to complete the processing of this instruction.
SDNode *Select_ISD_STORE(const SDValue &N) { SDValue Chain = N.getOperand(0); if (Predicate_store(N.getNode())) { SDValue N1 = N.getOperand(1); SDValue N2 = N.getOperand(2); SDValue CPTmp0; SDValue CPTmp1; // Pattern: (st:void IntRegs:i32:$src, // ADDRrr:i32:$addr)<<P:Predicate_store>> // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src) // Pattern complexity = 13 cost = 1 size = 0 if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) && N1.getNode()->getValueType(0) == MVT::i32 && N2.getNode()->getValueType(0) == MVT::i32) { return Emit_22(N, SP::STrr, CPTmp0, CPTmp1); } ...
The Legalize phase converts a DAG to use types and operations that are natively supported by the target. For natively unsupported types and operations, you need to add code to the target-specific XXXTargetLowering implementation to convert unsupported types and operations to supported ones.
In the constructor for the XXXTargetLowering class, first use the addRegisterClass method to specify which types are supports and which register classes are associated with them. The code for the register classes are generated by TableGen from XXXRegisterInfo.td and placed in XXXGenRegisterInfo.h.inc. For example, the implementation of the constructor for the SparcTargetLowering class (in SparcISelLowering.cpp) starts with the following code:
addRegisterClass(MVT::i32, SP::IntRegsRegisterClass); addRegisterClass(MVT::f32, SP::FPRegsRegisterClass); addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
You should examine the node types in the ISD namespace (include/llvm/CodeGen/SelectionDAGNodes.h) and determine which operations the target natively supports. For operations that do not have native support, add a callback to the constructor for the XXXTargetLowering class, so the instruction selection process knows what to do. The TargetLowering class callback methods (declared in llvm/Target/TargetLowering.h) are:
Note: on older releases, setLoadXAction is used instead of setLoadExtAction. Also, on older releases, setCondCodeAction may not be supported. Examine your release to see what methods are specifically supported.
These callbacks are used to determine that an operation does or does not work with a specified type (or types). And in all cases, the third parameter is a LegalAction type enum value: Promote, Expand, Custom, or Legal. SparcISelLowering.cpp contains examples of all four LegalAction values.
For an operation without native support for a given type, the specified type may be promoted to a larger type that is supported. For example, SPARC does not support a sign-extending load for Boolean values (i1 type), so in SparcISelLowering.cpp the third parameter below, Promote, changes i1 type values to a large type before loading.
setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
For a type without native support, a value may need to be broken down further, rather than promoted. For an operation without native support, a combination of other operations may be used to similar effect. In SPARC, the floating-point sine and cosine trig operations are supported by expansion to other operations, as indicated by the third parameter, Expand, to setOperationAction:
setOperationAction(ISD::FSIN, MVT::f32, Expand); setOperationAction(ISD::FCOS, MVT::f32, Expand);
For some operations, simple type promotion or operation expansion may be insufficient. In some cases, a special intrinsic function must be implemented.
For example, a constant value may require special treatment, or an operation may require spilling and restoring registers in the stack and working with register allocators.
As seen in SparcISelLowering.cpp code below, to perform a type conversion from a floating point value to a signed integer, first the setOperationAction should be called with Custom as the third parameter:
setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
In the LowerOperation method, for each Custom operation, a case statement should be added to indicate what function to call. In the following code, an FP_TO_SINT opcode will call the LowerFP_TO_SINT method:
SDValue SparcTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) { switch (Op.getOpcode()) { case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG); ... } }
Finally, the LowerFP_TO_SINT method is implemented, using an FP register to convert the floating-point value to an integer.
static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) { assert(Op.getValueType() == MVT::i32); Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0)); return DAG.getNode(ISD::BITCAST, MVT::i32, Op); }
The Legal LegalizeAction enum value simply indicates that an operation is natively supported. Legal represents the default condition, so it is rarely used. In SparcISelLowering.cpp, the action for CTPOP (an operation to count the bits set in an integer) is natively supported only for SPARC v9. The following code enables the Expand conversion technique for non-v9 SPARC implementations.
setOperationAction(ISD::CTPOP, MVT::i32, Expand); ... if (TM.getSubtarget<SparcSubtarget>().isV9()) setOperationAction(ISD::CTPOP, MVT::i32, Legal); case ISD::SETULT: return SPCC::ICC_CS; case ISD::SETULE: return SPCC::ICC_LEU; case ISD::SETUGT: return SPCC::ICC_GU; case ISD::SETUGE: return SPCC::ICC_CC; } }
To support target-specific calling conventions, XXXGenCallingConv.td uses interfaces (such as CCIfType and CCAssignToReg) that are defined in lib/Target/TargetCallingConv.td. TableGen can take the target descriptor file XXXGenCallingConv.td and generate the header file XXXGenCallingConv.inc, which is typically included in XXXISelLowering.cpp. You can use the interfaces in TargetCallingConv.td to specify:
The following example demonstrates the use of the CCIfType and CCAssignToReg interfaces. If the CCIfType predicate is true (that is, if the current argument is of type f32 or f64), then the action is performed. In this case, the CCAssignToReg action assigns the argument value to the first available register: either R0 or R1.
CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
SparcCallingConv.td contains definitions for a target-specific return-value calling convention (RetCC_Sparc32) and a basic 32-bit C calling convention (CC_Sparc32). The definition of RetCC_Sparc32 (shown below) indicates which registers are used for specified scalar return types. A single-precision float is returned to register F0, and a double-precision float goes to register D0. A 32-bit integer is returned in register I0 or I1.
def RetCC_Sparc32 : CallingConv<[ CCIfType<[i32], CCAssignToReg<[I0, I1]>>, CCIfType<[f32], CCAssignToReg<[F0]>>, CCIfType<[f64], CCAssignToReg<[D0]>> ]>;
The definition of CC_Sparc32 in SparcCallingConv.td introduces CCAssignToStack, which assigns the value to a stack slot with the specified size and alignment. In the example below, the first parameter, 4, indicates the size of the slot, and the second parameter, also 4, indicates the stack alignment along 4-byte units. (Special cases: if size is zero, then the ABI size is used; if alignment is zero, then the ABI alignment is used.)
def CC_Sparc32 : CallingConv<[ // All arguments get passed in integer registers if there is space. CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>, CCAssignToStack<4, 4> ]>;
CCDelegateTo is another commonly used interface, which tries to find a specified sub-calling convention, and, if a match is found, it is invoked. In the following example (in X86CallingConv.td), the definition of RetCC_X86_32_C ends with CCDelegateTo. After the current value is assigned to the register ST0 or ST1, the RetCC_X86Common is invoked.
def RetCC_X86_32_C : CallingConv<[ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>, CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>, CCDelegateTo<RetCC_X86Common> ]>;
CCIfCC is an interface that attempts to match the given name to the current calling convention. If the name identifies the current calling convention, then a specified action is invoked. In the following example (in X86CallingConv.td), if the Fast calling convention is in use, then RetCC_X86_32_Fast is invoked. If the SSECall calling convention is in use, then RetCC_X86_32_SSE is invoked.
def RetCC_X86_32 : CallingConv<[ CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>, CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>, CCDelegateTo<RetCC_X86_32_C> ]>;
Other calling convention interfaces include:
During the code emission stage, the code generator may utilize an LLVM pass to produce assembly output. To do this, you want to implement the code for a printer that converts LLVM IR to a GAS-format assembly language for your target machine, using the following steps:
The code in XXXTargetAsmInfo.h is usually a trivial declaration of the XXXTargetAsmInfo class for use in XXXTargetAsmInfo.cpp. Similarly, XXXTargetAsmInfo.cpp usually has a few declarations of XXXTargetAsmInfo replacement values that override the default values in TargetAsmInfo.cpp. For example in SparcTargetAsmInfo.cpp:
SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) { Data16bitsDirective = "\t.half\t"; Data32bitsDirective = "\t.word\t"; Data64bitsDirective = 0; // .xword is only supported by V9. ZeroDirective = "\t.skip\t"; CommentString = "!"; ConstantPoolSection = "\t.section \".rodata\",#alloc\n"; }
The X86 assembly printer implementation (X86TargetAsmInfo) is an example where the target specific TargetAsmInfo class uses an overridden methods: ExpandInlineAsm.
A target-specific implementation of AsmPrinter is written in XXXAsmPrinter.cpp, which implements the AsmPrinter class that converts the LLVM to printable assembly. The implementation must include the following headers that have declarations for the AsmPrinter and MachineFunctionPass classes. The MachineFunctionPass is a subclass of FunctionPass.
#include "llvm/CodeGen/AsmPrinter.h" #include "llvm/CodeGen/MachineFunctionPass.h"
As a FunctionPass, AsmPrinter first calls doInitialization to set up the AsmPrinter. In SparcAsmPrinter, a Mangler object is instantiated to process variable names.
In XXXAsmPrinter.cpp, the runOnMachineFunction method (declared in MachineFunctionPass) must be implemented for XXXAsmPrinter. In MachineFunctionPass, the runOnFunction method invokes runOnMachineFunction. Target-specific implementations of runOnMachineFunction differ, but generally do the following to process each machine function:
The XXXAsmPrinter implementation must also include the code generated by TableGen that is output in the XXXGenAsmWriter.inc file. The code in XXXGenAsmWriter.inc contains an implementation of the printInstruction method that may call these methods:
The implementations of printDeclare, printImplicitDef, printInlineAsm, and printLabel in AsmPrinter.cpp are generally adequate for printing assembly and do not need to be overridden.
The printOperand method is implemented with a long switch/case statement for the type of operand: register, immediate, basic block, external symbol, global address, constant pool index, or jump table index. For an instruction with a memory address operand, the printMemOperand method should be implemented to generate the proper output. Similarly, printCCOperand should be used to print a conditional operand.
doFinalization should be overridden in XXXAsmPrinter, and it should be called to shut down the assembly printer. During doFinalization, global variables and constants are printed to output.
Subtarget support is used to inform the code generation process of instruction set variations for a given chip set. For example, the LLVM SPARC implementation provided covers three major versions of the SPARC microprocessor architecture: Version 8 (V8, which is a 32-bit architecture), Version 9 (V9, a 64-bit architecture), and the UltraSPARC architecture. V8 has 16 double-precision floating-point registers that are also usable as either 32 single-precision or 8 quad-precision registers. V8 is also purely big-endian. V9 has 32 double-precision floating-point registers that are also usable as 16 quad-precision registers, but cannot be used as single-precision registers. The UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set extensions.
If subtarget support is needed, you should implement a target-specific XXXSubtarget class for your architecture. This class should process the command-line options -mcpu= and -mattr=.
TableGen uses definitions in the Target.td and Sparc.td files to generate code in SparcGenSubtarget.inc. In Target.td, shown below, the SubtargetFeature interface is defined. The first 4 string parameters of the SubtargetFeature interface are a feature name, an attribute set by the feature, the value of the attribute, and a description of the feature. (The fifth parameter is a list of features whose presence is implied, and its default value is an empty array.)
class SubtargetFeature<string n, string a, string v, string d, list<SubtargetFeature> i = []> { string Name = n; string Attribute = a; string Value = v; string Desc = d; list<SubtargetFeature> Implies = i; }
In the Sparc.td file, the SubtargetFeature is used to define the following features.
def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true", "Enable SPARC-V9 instructions">; def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8", "V8DeprecatedInsts", "true", "Enable deprecated V8 instructions in V9 mode">; def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true", "Enable UltraSPARC Visual Instruction Set extensions">;
Elsewhere in Sparc.td, the Proc class is defined and then is used to define particular SPARC processor subtypes that may have the previously described features.
class Proc<string Name, list<SubtargetFeature> Features> : Processor<Name, NoItineraries, Features>; def : Proc<"generic", []>; def : Proc<"v8", []>; def : Proc<"supersparc", []>; def : Proc<"sparclite", []>; def : Proc<"f934", []>; def : Proc<"hypersparc", []>; def : Proc<"sparclite86x", []>; def : Proc<"sparclet", []>; def : Proc<"tsc701", []>; def : Proc<"v9", [FeatureV9]>; def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>; def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>; def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
From Target.td and Sparc.td files, the resulting SparcGenSubtarget.inc specifies enum values to identify the features, arrays of constants to represent the CPU features and CPU subtypes, and the ParseSubtargetFeatures method that parses the features string that sets specified subtarget options. The generated SparcGenSubtarget.inc file should be included in the SparcSubtarget.cpp. The target-specific implementation of the XXXSubtarget method should follow this pseudocode:
XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) { // Set the default features // Determine default and user specified characteristics of the CPU // Call ParseSubtargetFeatures(FS, CPU) to parse the features string // Perform any additional operations }
The implementation of a target machine optionally includes a Just-In-Time (JIT) code generator that emits machine code and auxiliary structures as binary output that can be written directly to memory. To do this, implement JIT code generation by performing the following steps:
There are several different approaches to writing the JIT support code. For instance, TableGen and target descriptor files may be used for creating a JIT code generator, but are not mandatory. For the Alpha and PowerPC target machines, TableGen is used to generate XXXGenCodeEmitter.inc, which contains the binary coding of machine instructions and the getBinaryCodeForInstr method to access those codes. Other JIT implementations do not.
Both XXXJITInfo.cpp and XXXCodeEmitter.cpp must include the llvm/CodeGen/MachineCodeEmitter.h header file that defines the MachineCodeEmitter class containing code for several callback functions that write data (in bytes, words, strings, etc.) to the output stream.
In XXXCodeEmitter.cpp, a target-specific of the Emitter class is implemented as a function pass (subclass of MachineFunctionPass). The target-specific implementation of runOnMachineFunction (invoked by runOnFunction in MachineFunctionPass) iterates through the MachineBasicBlock calls emitInstruction to process each instruction and emit binary code. emitInstruction is largely implemented with case statements on the instruction types defined in XXXInstrInfo.h. For example, in X86CodeEmitter.cpp, the emitInstruction method is built around the following switch/case statements:
switch (Desc->TSFlags & X86::FormMask) { case X86II::Pseudo: // for not yet implemented instructions ... // or pseudo-instructions break; case X86II::RawFrm: // for instructions with a fixed opcode value ... break; case X86II::AddRegFrm: // for instructions that have one register operand ... // added to their opcode break; case X86II::MRMDestReg:// for instructions that use the Mod/RM byte ... // to specify a destination (register) break; case X86II::MRMDestMem:// for instructions that use the Mod/RM byte ... // to specify a destination (memory) break; case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte ... // to specify a source (register) break; case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte ... // to specify a source (memory) break; case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data ... break; case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data ... break; case X86II::MRMInitReg: // for instructions whose source and ... // destination are the same register break; }
The implementations of these case statements often first emit the opcode and then get the operand(s). Then depending upon the operand, helper methods may be called to process the operand(s). For example, in X86CodeEmitter.cpp, for the X86II::AddRegFrm case, the first data emitted (by emitByte) is the opcode added to the register operand. Then an object representing the machine operand, MO1, is extracted. The helper methods such as isImmediate, isGlobalAddress, isExternalSymbol, isConstantPoolIndex, and isJumpTableIndex determine the operand type. (X86CodeEmitter.cpp also has private methods such as emitConstant, emitGlobalAddress, emitExternalSymbolAddress, emitConstPoolAddress, and emitJumpTableAddress that emit the data into the output stream.)
case X86II::AddRegFrm: MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg())); if (CurOp != NumOps) { const MachineOperand &MO1 = MI.getOperand(CurOp++); unsigned Size = X86InstrInfo::sizeOfImm(Desc); if (MO1.isImmediate()) emitConstant(MO1.getImm(), Size); else { unsigned rt = Is64BitMode ? X86::reloc_pcrel_word : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word); if (Opcode == X86::MOV64ri) rt = X86::reloc_absolute_dword; // FIXME: add X86II flag? if (MO1.isGlobalAddress()) { bool NeedStub = isa<Function>(MO1.getGlobal()); bool isLazy = gvNeedsLazyPtr(MO1.getGlobal()); emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0, NeedStub, isLazy); } else if (MO1.isExternalSymbol()) emitExternalSymbolAddress(MO1.getSymbolName(), rt); else if (MO1.isConstantPoolIndex()) emitConstPoolAddress(MO1.getIndex(), rt); else if (MO1.isJumpTableIndex()) emitJumpTableAddress(MO1.getIndex(), rt); } } break;
In the previous example, XXXCodeEmitter.cpp uses the variable rt, which is a RelocationType enum that may be used to relocate addresses (for example, a global address with a PIC base offset). The RelocationType enum for that target is defined in the short target-specific XXXRelocations.h file. The RelocationType is used by the relocate method defined in XXXJITInfo.cpp to rewrite addresses for referenced global symbols.
For example, X86Relocations.h specifies the following relocation types for the X86 addresses. In all four cases, the relocated value is added to the value already in memory. For reloc_pcrel_word and reloc_picrel_word, there is an additional initial adjustment.
enum RelocationType { reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base reloc_absolute_word = 2, // absolute relocation; no additional adjustment reloc_absolute_dword = 3 // absolute relocation; no additional adjustment };
XXXJITInfo.cpp implements the JIT interfaces for target-specific code-generation activities, such as emitting machine code and stubs. At minimum, a target-specific version of XXXJITInfo implements the following:
getLazyResolverFunction is generally trivial to implement. It makes the incoming parameter as the global JITCompilerFunction and returns the callback function that will be used a function wrapper. For the Alpha target (in AlphaJITInfo.cpp), the getLazyResolverFunction implementation is simply:
TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction( JITCompilerFn F) { JITCompilerFunction = F; return AlphaCompilationCallback; }
For the X86 target, the getLazyResolverFunction implementation is a little more complication, because it returns a different callback function for processors with SSE instructions and XMM registers.
The callback function initially saves and later restores the callee register values, incoming arguments, and frame and return address. The callback function needs low-level access to the registers or stack, so it is typically implemented with assembler.


Coding-Java-Questions
About this repository
The inception of this repository is aimed at creating a one-stop shop for all common and most asked questions about Java programming language in an interview setting. The list of current contributors is as follows:
- Neeraj Choudhary
- Naveen Kumar Chauhan
- Naveen Chakravarthy Balasubramanian
About Java
Java was developed by Sun Microsystems Inc. in the year 1991, later acquired by Oracle Corporation. It was developed by James Gosling and Patrik Naughton. Java is a class-based, object-oriented programming language
and is designed to have as few implementation dependencies as possible. Java applications are compiled to byte code that can run on any Java Virtual Machine (JVM).
Basic Terminology
- Java Development Kit (JDK):
It is a complete kit that includes everthing including compiler, Java Runtime Environment (JRE), debuggers, samples, documentation etc.
- Java Virtual Machine (JVM):
JVM executes the bytecode generated by the Java compiler.
- Bytecode:
Javac compiler of JDK compiles the Java source code into bytecode so that it can be executed by JVM. It is saved as .class file by the compiler.
- Java Runtime Environment (JRE):
JDE includes JRE to run the java programs after compilation.
- Garbage Collector:
For memory management, JVM has a program that take care to recollect the memory that are not referenced. This program is known as Garbage collector.
- ClassPath:
This is a file path where Java runtime and Java compiler search for .class files and external libraries to load.
Created as part of Open Source Software Engineering Assignment. No Copyright Infringement Intended.


Running CODED¶
Instructions on running CODED.
First, load the CODED module:
var codedUtils = require('users/bullocke/coded:v0.2/changeDetection')
Define the study area, with ‘region’ being an import or path to a feature.
var saveRegion = ee.FeatureCollection(region)
Define the sample name and parameters:
var sampleName = ee.FeatureCollection('users/bullockebu/amazon/samples/sample1')
var params = ee.Dictionary({
'consec': 3,
'thresh': 3,
'start': 1990,
'end': 2018,
'trainDataEnd': 2016,
'trainDataStart': 2013,
'trainLength': 3,
'soil': [2000, 3000, 3400, 5800, 6000, 5800],
'gv': [500, 900, 400, 6100, 3000, 1000],
'npv': [1400, 1700, 2200, 3000, 5500, 3000],
'shade': [0, 0, 0, 0, 0, 0],
'cloud': [9000, 9600, 8000, 7800, 7200, 6500],
'cfThreshold': .05,
'forestLabel': 1,
'minYears': 3
})
Call the main function of CODED to retrieve the results:
var results = codedUtils.submitCODED(saveRegion, params, trainingData)
The output of the change detection is an array image. At every pixel location there is an array matrix, with a row for every year in the study period and the columns corresponding to the a change flag (1 = change, 0 = no change), change magnitude, post-change land cover, NDFI difference band, and a forest flag (1 = forest in training period).
| Column | Range | Description |
|---|---|---|
| 1 | 0-1 | Change flag with 1 indicating change |
| 2 | 0-255 | Change magnitude with higher values representing higher magnitude |
| 3 | 1-#C | Post-change land cover corrresponding to label in training data (1 - # of classes) |
| 4 | 0-255 | Difference in NDFI expressed as percent NDFI magnitude after disturbance compared to before |
| 5 | 0-1 | Forest flag with 1 representing forest in training period |
The data array that CODED returns can not be saved as an output or asset. The array image needs to be projected as a saveable 3-D image (x, y, and band dimensions).
First, it helps to define a function to create band names:
var makeBands = function(start, end, prefix) {
var bandSeq = ee.List.sequence(start, end)
var bandList = bandSeq.map(function(i) {
return ee.String(prefix).cat(ee.String(i).slice(0,4))
})
return bandList
}
Next, use a combination of arraySlice, arrayProject, and arrayFlatten to turn one column of the array image into a 3D image with one band for each year:
var makeImage = function(arrayImage, column, bandPrefix, start, end) {
var bandList = makeBands(start, end, bandPrefix)
return arrayImage.arraySlice(1, ee.Number(column), ee.Number(column).add(1))
.arrayProject([0])
.arrayFlatten([bandList])
}
var column = 0 // change flag
var bandPrefix = 'distFlag_' // band prefix
var start = params.get('start') // first year of study period
var end = params.get('end') // last year of study period
var distFlagImage = makeImage(results, column, bandPrefix, start, end)
If you create images of all the outputs the images will contain a lot of bands - likely not all of them are necessary. The dataUtils file contains a function to reduce the bands to 4 times the number of changes specified in the parameter dictionary. The output bands are the date of first change, magnitude of first change, the land cover after the first change, the difference in NDFI from before and after the change, the date of second change, and so on. In the following example the CODED output array is turned into 5 images, and then reduced to a smaller image while keeping all the forest flags and attaching the parameter dictionary to the image attributes.
var dataUtils = require('users/bullocke/coded:v0.2/dataUtils')
var disturbances = dataUtils.makeImage(results, 0, 'dist_', start, end)
var magnitude = dataUtils.makeImage(results, 1, 'mag_', start, end)
var postChange = dataUtils.makeImage(results, 2, 'post_', start, end)
var difference = dataUtils.makeImage(results, 3, 'dif_', start, end)
var forestFlag = dataUtils.makeImage(results, 4, 'forest_', start, end)
var disturbanceBands = disturbances.addBands([magnitude, postChange, difference])
var saveOutput = ee.Image(dataUtils.reduceBands(ee.Image(disturbanceBands), params)
.setMulti(params))
.addBands(forestFlag)
The results can then be submitted as a task:
Export.image.toAsset({
image: saveOutput,
description: 'imageDescription',
assetId: 'path/imageDescription',
maxPixels:<PHONE_NUMBER>000,
scale: 30,
region: saveRegion.geometry(),
})


Approximate calculation of the mean convective heat transfer coefficient kc for forced convection with a fully developed fluid flow in a turbulent regime.
A detailed documentation for this convective heat transfer calculation can be found in its underlying function kc_approxForcedConvection_KC . Note that additionally a failure status is observed in this function to check if the intended boundary conditions are fulfilled. See more information .
function kc_approxForcedConvection extends Modelica.Icons.Function; input Modelica.Fluid.Dissipation.HeatTransfer.General.kc_approxForcedConvection_IN_con IN_con "Input record for function kc_approxForcedConvection" annotation( Dialog(group = "Constant inputs")); input Modelica.Fluid.Dissipation.HeatTransfer.General.kc_approxForcedConvection_IN_var IN_var "Input record for function kc_approxForcedConvection" annotation( Dialog(group = "Variable inputs")); output SI.CoefficientOfHeatTransfer kc "Convective heat transfer coefficient" annotation( Dialog(group = "Output")); output SI.PrandtlNumber Pr "Prandtl number" annotation( Dialog(group = "Output")); output SI.ReynoldsNumber Re "Reynolds number" annotation( Dialog(group = "Output")); output SI.NusseltNumber Nu "Nusselt number" annotation( Dialog(group = "Output")); output Real failureStatus "0== boundary conditions fulfilled | 1== failure >> check if still meaningful results" annotation( Dialog(group = "Output")); end kc_approxForcedConvection;


Description: {{weapon_detail.description}}
Color: {{weapon_detail.color}}
Damage: {{weapon_detail.damage}}


Money Play. How should Red play 42?
pips Red=135 White=114
(CorrectAnswer= 0/0, ErrorScore= 0)
This is a nice easy one as 13/9, 8/6 does nothing to improve Red’s position.
13/7 is the right play with the intention of making a five-point prime next turn.
Red is not favourite in the position but he needs to make the most of what the dice have given him.
13/7 is the right play with the intention of making a five-point prime next turn.
Red is not favourite in the position but he needs to make the most of what the dice have given him.
1. Cubeful 2-ply 13/7 Eq.: -0.424 0.385 0.073 0.003 - 0.615 0.138 0.005 2. Cubeful 2-ply 13/9 8/6 Eq.: -0.510 (-0.086) 0.349 0.070 0.002 - 0.651 0.107 0.004 3. Cubeful 2-ply 9/5 8/6 Eq.: -0.511 (-0.087) 0.361 0.077 0.003 - 0.639 0.142 0.008 4. Cubeful 2-ply 13/9 4/2 Eq.: -0.535 (-0.111) 0.348 0.064 0.002 - 0.652 0.122 0.005 5. Cubeful 2-ply 13/11 8/4 Eq.: -0.538 (-0.115) 0.350 0.065 0.002 - 0.650 0.141 0.007


| Title | Posted | Location | ACTIONS |
|---|---|---|---|
| {{job.title}} | {{job.createdAt | date:'dd MMM yyyy'}} | {{job.location}} | |
{{job.title}}{{job.jobType==0?"Permanent":"Contract"}} | ${{job.compensation}} | Pay: {{job.payrateType}} | Currency: {{job.currency}} | Experience: {{job.minimumExperience}} - {{job.maximumExperience}}(years) | {{job.location}} | {{job.createdAt | date:'dd MMM yyyy'}} {{skill}} Description: |


This sample demonstrates how to call Windows.Security.Authentication.OnlineId APIs to authenticate a user with Microsoft account and use JWT tokens.
If you want to register your application, please see the documentation on Developer Center for more details.
To sign out from the Windows application, go to the Settings charm.


Learn You a Python is an online resource created with the aim of helping anyone with any skill level to learn the programming language Python in a project-based approach. The progression is going to follow a roadmap-like structure. People should feel free to start at any checkpoint and jump around if they feel comfotrable. Topics are going to be presented and explained in an application that actually performs something that might be useful and you will rarely encounter foo bar biz . This is still a work in progress and has not been proofread yet, feedback and suggestions are highly encouraged. You can reach me using email.
This work is not meant to be a standalone resource. The best way to learn any programming language (and probably anything in life) is to tap into multiple resources and try to absorb as much as you can.
Select a checkpoint to start at


Please upload your profile, master, and incoming spreadsheets. Enter a points value below which results will not be displayed (a low cutoff will result in large numbers of irrelevant results) and specify the name of the primary key column in the master spreadsheet.


This page demonstrates using GTEx Expression Heatmap to display and summarize top expressed genes.
Select a tissue to view its top 50 expressed genes and all of their available expression data across all GTEx tissues. By default, mitochondrial genes are excluded from the top expressed gene list. The rows of the heatmap are genes, columns are tissues (color-coded by the tissue types), and colors are scaled by median expression values. By default, the gene rows and tissue columns are hierarchically clustered using the Euclidean distance and average linkage method.


{{ vm.catalog.types[0].name }}
{{ item.priceSmall }}
{{item.description}}
The price list is based on the vendor for today. This venue can only be changed by an administrator. The selected venue is "{{ vm.catalog.name }}".
{{item.description}}
{{item.description}}
{{item.description}}


'Protest supporter' Lee reaches Hong Kong badminton final
HONG KONG: Lee Cheuk-yiu gave his protest-wracked home city something to cheer on Saturday (Nov 16) as he upset India's Kidambi Srikanth to reach the Hong Kong Open badminton final.
The 23-year-old, who caused a stir earlier in the tournament by appearing to show support for the months-long pro-democracy protests, beat Srikanth 21-9, 25-23.
Earlier, Thai former world champion Ratchanok Intanon overcame Japan's Akane Yamaguchi in three games to set up a women's singles final against Chen Yufei of China.
The tournament is taking place against the backdrop of escalating protests that caused widespread disruption and violence across Hong Kong this week.
Lee, world-ranked 27th, is now into the biggest final of his career after extending a dream run that includes victory over Denmark's Viktor Axelsen in the last eight.
On Sunday he will play Anthony Ginting, who won an all-Indonesian clash 22-20, 13-21, 21-18 against Jonatan Christie.
Lee made headlines after his opening match when he held up an outstretched right hand and his left index finger, in a gesture interpreted as supporting 'Five demands, not one less' -- a slogan chanted by the protesters.
"Those who understand will understand, those who don't, just forget it," Lee said this week when asked to explain his celebration, according to the South China Morning Post.
"We don't only show our determination on the badminton court, we can also show it in other aspects," he added.
Earlier Ratchanok fought back from a game down to beat Yamaguchi 21-23, 21-15, 21-12 and set up a final with Chen, who appeared to be feeling the pace after her title run last week in Fuzhou.
"She will be a bit tired from last week, and here also she looked tired. She has a good defence. I will try to do my best, I won't think about my weakness," Ratchanok said, according to the Badminton World Federation website.
Chen laboured to a 21-18, 14-21, 21-15 win over Chinese-born American Zhang Beiwen, who spoke of her astonishment at the scenes she had witnessed in Hong Kong, where protesters blocked major routes and set fire to toll booths.
"I have travelled on tour for many years and this is the most serious incident I have ever come across," said Zhang, according to the Post.
"The fires were so terrible while the protesters in full gear look like those found in video games. It was quite scary."


A creed is a statement of belief usually religious belief or faith often recited as part of a religious service. The word derives from the Latin: credo for "I believe" (because the Latin translation of the Apostles' Creed and the Nicene Creed both begin with this word). A creed is sometimes referred to as a symbol (Greek: σύμβολο[ν], sýmbolo[n]), signifying a "token" by which persons of like beliefs might recognize each other.
One of the most widely used creeds in Christianity is the Nicene Creed, first formulated in AD 325 at the First Council of Nicaea. It was based on Christian understanding of the Canonical gospels, the letters of the New Testament and to a lesser extent the Old Testament. Affirmation of this creed, which describes the Trinity, is generally taken as a fundamental test of orthodoxy for mostChristian denominations. The Apostles' Creed is also broadly accepted. Some Christian denominations and other groups have rejected the authority of those creeds.
Whether Judaism is creedal has been a point of some controversy. Though some say Judaism is noncreedal in nature, others say it recognizes a single creed, the Shema which begins: "Hear, O Israel: the LORD our God, the LORD is one."
Muslims declare the shahada, or testimony: "I bear witness that there is no god but God, and that Muhammad is His messenger."


Rich Trott / @Trott
9.0.0 is not slated for LTS.
I'm doing the best I can.
try { Buffer.from({}); } catch (e) { console.log(e.code); // 'ERR_INVALID_ARG_TYPE' }
…is usually terrible so we'll be skipping it.
Come and talk to me or find me on Twitter or something.
Rich Trott / @Trott


| Accordion |
An Accordion here is a list of ControlGroups which can be expanded and collapsed.
|
| Background |
controlP5 is a processing gui library.
|
| Bang |
The Bang controller triggers an event when pressed.
|
| BitFont |
|
| Button |
A button triggers an event after it has been release.
|
| ButtonBar |
|
| CallbackEvent |
A CallbackEvent is send when a controller action such as enter, leave, press, etc has occurs.
|
| Canvas |
Use a Canvas to draw custom graphics into a control
window or the default sketch window.
|
| CColor |
A CColor instance contains the colors of a controller including the foreground-, background-,
active-, captionlabel- and valuelabel-colors.
|
| Chart |
Use charts to display float array data as line chart, yet experimental, but see the
ControlP5chart example for more details.
|
| ChartData |
Used by Chart, single chart data is stored here including value, (label) text, and color.
|
| ChartDataSet |
Used by Chart, a chart data set is a container to store chart data.
|
| CheckBox |
A multiple-choice radioButton.
|
| ColorPicker |
A simple color picker using sliders to adjust RGBA values.
|
| ColorWheel |
|
| ControlBehavior |
The abstract class control behavior allows you to add custom behavior to controllers.
|
| ControlBroadcaster |
The ControlBroadcaster handles all controller value changes and distributes them accordingly to
its listeners.
|
| ControlEvent |
A controlEvent is sent to a PApplet or a ControlListener whenever a controller value has changed.
|
| ControlFont |
A ControlFont is a container for a PFont that can be used to customize the font of a label.
|
| ControlGroup<T> |
In previous versions you would use the ControlGroup class
to bundle controllers in a group.
|
| Controller<T> |
Controller is an abstract class that is extended by any available controller within controlP5.
|
| ControllerGroup<T> |
ControllerGroup is an abstract class and is extended by class ControlGroup, Tab, or the ListBox.
|
| ControllerList |
Stores objects of type ControllerInterface and CDrawable, mainly for internal use.
|
| ControllerPlug |
The ControllerPlug is used to do all the reflection procedures to link a controller to a variable
or function inside your main application.
|
| ControllerProperties |
Values of controllers can be stored inside properties files which can be saved to file or memory.
|
| ControllerProperty |
A controller property saves the value, address, getter and setter of a registered controller.
|
| ControllerStyle |
Labels use the ControllerStyle class to store margin and padding information.
|
| ControlP5 |
controlP5 is a processing and java library for creating
simple control GUIs.
|
| ControlP5Base |
The ControlP5Base supports the ControlP5 class and
implements all adder methods to add controllers to
controlP5.
|
| ControlP5Legacy |
|
| ControlTimer |
control timer is a timer that can be used for example as a stop watch or a duration timer.
|
| ControlWindow |
|
| CP |
|
| DropdownList |
controlP5 is a processing gui library.
|
| DropdownList.DropdownListView |
|
| FrameRate |
|
| Group |
controlP5 is a processing gui library.
|
| Icon |
|
| Knob |
A knob is a circular slider which can be used with a limited and unlimited range.
|
| Label |
A custom label using controlP5's BitFonts or PFont based
ControlFonts.
|
| ListBox |
A ListBox is a list of vertically aligned items which can be scrolled if required.
|
| ListBox.ListBoxView |
|
| Matrix |
A matrix is a 2d array with a pointer that traverses through the matrix in a timed interval.
|
| MultiList |
A Multilist is a multi-menu-tree controller.
|
| MultiListButton |
Used by MultiList.
|
| Numberbox |
Click and drag the mouse inside a numberbox and move up and down to change the value of a
numberbox.
|
| Println |
|
| Radio |
controlP5 is a processing gui library.
|
| RadioButton |
A radioButton is a list of toggles that can be turned on or off.
|
| Range |
A range slider works just like a slider but can be adjusted on both ends.
|
| ScrollableList |
A ScrollableList is a list of vertically aligned items
which can be scrolled if required.
|
| ScrollableList.ScrollableListView |
|
| Slider |
A slider is either used horizontally or vertically.
|
| Slider2D |
The Slider2D allows to control a handle within a 2D area.
|
| Spacer |
|
| Tab |
Tabs are used to organize controllers.
|
| Textarea |
a textarea can be used to leave notes, it uses the controlP5 BitFont to render text.
|
| Textfield |
A singleline input textfield, use arrow keys to go back and forth, use backspace to delete
characters.
|
| Textlabel |
|
| TickMark |
Tickmarks are used by the Slider and Knob controller.
|
| Toggle |
a toggle can have two states, true and false, where true has the value 1 and false is 0.
|
| Tooltip |
A tooltip can be registered for individual controllers
and is activated on rollover.
|


{% load i18n%} {% load consulting %} {% url consulting_newpatient as newpatient %} {% url cal.index as cal %}


Blander
------------------------------
Building a Quant Trading Startup with a World-Class Research Culture
------------------------------
Presented by Blander Technologies founder and CEO, Ben Blander, math Ph.D and former head of Citadel’s high-frequency group
WEDNESDAY, SEPTEMBER 25
6:00 PM
LEWIS LIBRARY 138
DINNER PROVIDED FROM OLIVES
To help us order enough food, please RSVP at
http://tinyurl.com/
ALL MAJORS & CLASS YEARS WELCOME
------------------------------
What you'll learn
------------------------------
- why high-frequency trading is in decline and research-based trading is on the rise
- what you’ll have to learn and unlearn to become a leader in the trading industry
- the advantages and challenges of starting a trading firm from scratch
- how the opportunity of a quant trading startup stacks up to software startups
------------------------------
about Blander Technologies
------------------------------
Blander Technologies is a research-driven, proprietary trading firm in Chicago.
We’re an emerging startup led by Ben Blander, former head of Citadel’s high frequency group and a key contributor in growing their P&L from $75 million in 2005 to $1.15 billion in 2008 (Source:
http://www.
Previously Ben earned a PhD in Math from the University of Chicago.
We’re building a new type of trading firm dedicated to research through open, collaborative innovation. All our associates operate from somewhere on the continuum between these two roles:
- Technologists: Your goal is to enable alpha generation and improve the research infrastructure through technology innovation. You’ll also be expected to have a strong interest in understanding and contributing to our trading strategies.
- Quantitative researchers: While the focus is on identifying trading opportunities, you can add even more value with strong communication skills and some coding proficiency to accelerate the innovation process and help others leverage your work.
------------------------------
WHY TRADING?
------------------------------
If you want to work with huge data sets and cutting-edge technology to solve really tough problems, while getting near-immediate feedback on your best ideas, the trading industry is hard to beat. Every day we’re competing with some of the smartest, most driven people in the world trying to take your money -- and if you don’t stay at the very top of your game in research, technology, and economics, they will.
And while the highly-publicized wave of high-frequency or “flash” trading based on sheer speed of execution might have reached its limit, we see continued opportunities with our strategy of using statistical research to outsmart the competition.
------------------------------
Hope to see you this Wednesday, September 25th. To help us order enough food, please RSVP at
http://tinyurl.com/
QUESTIONS? Contact Quentin Ybarra


This small demo shows co-occurrence networks for all of Shakespeare's plays. For more details on the extraction of these networks, please refer to the GitHub repository or the accompanying paper Shall I compare thee to a network?—Visualizing the Topological Structure of Shakespeare's Plays. The demo uses a force-directed graph layout. Nodes are scaled according to their degree.
More information about the data post-processing, including a calculation of relevant network features, is available as a Tutorial for Aleph, a library for exploring persistent homology.


SARGASSO’s friends are the strength of our service. Together we create value for a wide variety of industries with an interest in the growing potential of the blue sectors. Co-operating with SARGASSO is a way in for other clusters to create value for their members.
When we recieve requests for partners outside of our own blue areas of expertise we reach out to our friends that have the same motivation as we do – to help companies grow, accelerate circular and sustainable solutions and to make business and contacts prosper.
Please get in touch if you are interested in co-operation!
COOPERATION THROUGH PROJECTSSARGASSO is connected to two different project to support with matchmaking and innovation; The Connected Ship and RAMSES
(through the E-LASS network).
Want to be our friend and recieve our proposals?
We're proud to partner with many well renowned organizations and networks in industries that see potential in blue growth. To find out more about their contact details, please click on the button below.
READ MOREIs an EU-funded project looking to prove the benefits of using lightweight materials in the maritime sector.
Learn more about the project
Is a project funded by the Nordic Innovation which focuses on the challenge of connecting ships throught the use of digital solutions.
Learn more about the project


SparseML 0.1¶
Libraries for state-of-the-art deep neural network optimization algorithms, enabling simple pipelines integration with a few lines of code
Overview¶
SparseML is a toolkit that includes APIs, CLIs, scripts and libraries that apply state-of-the-art optimization algorithms such as pruning and quantization to any neural network. General, recipe-driven approaches built around these optimizations enable the simplification of creating faster and smaller models for the ML performance community at large.
SparseML is integrated for easy model optimizations within the PyTorch, Keras, and TensorFlow V1 ecosystems currently.
Resources and Learning More¶
Release History¶
Official builds are hosted on PyPi - stable: sparseml - nightly (dev): sparseml-nightly
Additionally, more information can be found via GitHub Releases.


After the first list of films from 1988, my hunt is continuing. Difficult to find old movies on the "mainstreaming" platforms so I’ve started looking into Plex, which has, surprisingly, free films to stream with ads. Terrible ads, by the way. So this second part is a mixed bag of hand picked and random movies.
Digging in the carts
Black Eagle
Maybe films on Plex are as bad as theirs ads because this one is dreadful.
Black Eagle is about Shô Kosugi, specialist of ninja films who is not a ninja in this one but a special agent, codename Black Eagle (lol). He will fight against a Russian agent played by a young Jean-Claude Van Damme (just after Bloodsport).
Black Eagle has 2 weeks off, every year, to see his kids but this time, duty doesn’t wait and the mission is to scuba dive in Malta.
The film is just plain boring, the first fight scene happens after one and half hour and will only be followed by an other one.
Only two splits, the JCVD signature move.
Just a waste of time.
The Beast
Wow! What a great war film!
If we omit the Russians and Afghans played by Americans and that they are both a bit too much caricatural, it’s a big slap in the face.
From the first scene, the tone is set and I was hooked.
The pace is kept high just to slowly decrease until a final contemplative shot.
I was surprised multiple times by the madness of the leader, the film doesn’t hold back.
Very smart how The Beast shows the gore of war, either off screen or on screen but fast enough to not be too much, it’s more about feeling than showing.
The end is interesting, I think the main protagonist thought to have found a more civilised country in Afghanistan. But the women accomplishing their revenge is revealing to him that violence is everywhere, that the vicious circle will not end. Then he gives up on his new brothers in arms and returns home, pulled by another war machine.
Running on Empty
The scenario flows perfectly, the story looked simple to me at first, a family on the run, but it gives time to care about the main character going through his teenage years, torn between his family and the normal world. I loved the way they wait to show the mother play piano with him.
The end took me away, the unexpected reaction of the father, full of love and reassuring.
The two kids are so touching and endearing. The birthday scene is a very beautiful moment, so joyful that it made me think of the worst that could happen to this family. It touched me easily, without visible artifice, other than the music. I’m not the only one, this scene often comes up in other reviews. I think it is perfectly placed in the story and serves as a tipping point, the outside world finally pierced the family protective bubble.
From the cinematography to the characters development, everything is simple but beautiful, there is nothing to take out.
Call Me
Thanks again Plex to make me discover awful films (for free), this one is an obscure erotic thriller wannabe.
No scenes or dialogues are realistic. There is a murder at the beginning but all the main character is worried about is her phone stalker. And she’s seduced by him even if he’s the worst smooth talker ever.
The characters are mentioning multiple times "the Polish bar" like the writers didn’t bother to give it a name, that was the only funny thing.
I’m clearly not recommending to watch it! but you can see a young Steve Buscemi and also David Strathairn who was recently in the acclaimed Nomadland (2020).
Police Story 2
I have mixed feelings, the stunts and fights scenes are still excellent and there is choreography in every move but the film is too long and the plot is too complicated while not interesting.  Jackie Chan is unquestionably a master in action scenes, they are innovative, well written and well shot.
The film starts just after the first part where Jackie Chan’s character has to take responsibility for all the collateral damages he has done. But it quickly go back to normal and he will do more cop stuff. The film is generous in type of sequences and number of supporting characters but it’s just too lengthy to keep a good pace. Fun but less than the first Police Story.
Urgences
My first film from Depardon, while he’s a great French documentary filmmaker, I was mistaken him with Pierre Carles, to show my lacking culture about French documentaries.
It’s moving, it’s stranger than fiction. I got connected with people in a few minutes and was afraid for their future. It’s terribly sad to see some lost spirits like this.
The beginning was a bit slow and dry but, quickly, it presents really touching characters, the edit and directing can’t be more humble, the film only consists of long fixed shots that only move to follow the hectic movements of some patients. I love this system, it’s simple, states clearly from the beginning that they all agree to be filmed. I don’t have second thoughts on the making, like on The Vow, the HBO documentary about NXIVM cult, that I just finished watching the first season. It’s the opposite, no extra footage, no cliffhanger or any dishonest methods.
It’s covering a large spectrum of mental disease, light to severe, and all characters are iconic, it’s down-to-earth but incredible at the same time.
Fin


Gecode::Search::DFS Class Reference
#include <search.hh>
Inherited by Gecode::DFS< Test::Int::Scheduling::Ass >, and Gecode::DFS< T >.
Detailed Description
Depth-first search engine.This class implements depth-first exploration for spaces. In order to use depth-first search on subclasses of Space, additional functionality providing the necessary typecasts is available in Gecode::DFS.
Definition at line 417 of file search.hh.
Public Member Functions | |
| DFS (Space *s, unsigned int c_d, unsigned int a_d, Stop *st, size_t sz) | |
| Initialize search engine. | |
| Space * | next (void) |
| Return next solution (NULL, if none exists or search has been stopped). | |
| Statistics | statistics (void) const |
| Return statistics. | |
| bool | stopped (void) const |
| Check whether engine has been stopped. | |
Protected Attributes | |
| DfsEngine | e |
| Engine used for exploration. |
Constructor & Destructor Documentation
Member Function Documentation
| Space * Gecode::Search::DFS::next | ( | void | ) |
Return next solution (NULL, if none exists or search has been stopped).
Reimplemented in Gecode::DFS< T >, Gecode::Restart< T >, and Gecode::DFS< Test::Int::Scheduling::Ass >.
| Statistics Gecode::Search::DFS::statistics | ( | void | ) | const |
| bool Gecode::Search::DFS::stopped | ( | void | ) | const |
Member Data Documentation
DfsEngine Gecode::Search::DFS::e [protected] |
The documentation for this class was generated from the following files:
- gecode/search.hh (Revision: 7310)
- gecode/search/dfs.cc (Revision: 5916)


Bop It! Rhythm Game
I worked on this project as part of EECS 149, the embedded systems class at UC Berkeley. This project involved creating a responsive real-time game entirely on low-power hardware. We modified a Bop It! device to input its buttons into the microcontroller. All the code is worked on collaboratively on
Github.
This project involved creating a fun, polished, and responsive rhythm game that is all programmed in C. This allowed the game to be fast and responsive to register the player’s hits and misses well.
The technical aspects of this game include:
- Low-level programming
- Integration of separate devices
- Audio playback of MP3 through speakers
- Dealing with limited communication channels (I2C, SPI)


Gulp Boilerplate - EJS
is a tool that we designed to make it easier for developers (especially Front-end Developers) to create and create user interfaces as outlined in the visual web form of the design that has been determined.
Features
This WEB UIKIT provides a simple way of setting up a modern web development environment. Here is a list of the current features


A PDF copy of the instructions can be downloaded here for your convenience.
Step 1 - Downloading the Software
- Go to vpn.mtu.edu
- Enter your
Michigan Tech login
- Click “Download standalone VPN client for MS Windows”
- If your browser asks for permission to download the file, allow it.
Step 2 - Setting up the Software
- Install the file
- When it asks for your "customer information" (name and company), you can skip that stepor enter whatever you wish. The step does not matter.
- Click on the newly installed program,
F5 Networks
- F5 will ask you to
select Firepass Controller.
- It should already have "vpn.mtu.edu"entered.If it doesn't, then enter vpn.mtu.edu in that field.
- Enter your Michigan Tech
username and password.
- Go to the
folder list on the left. Under
“Network Access Controls,”
select
“Get an MTU address”
and click the
“Create”
button
-
Wait a short while until it reads
“Status: connected”
in the main window.
- Your firewall program may ask if you want to let the F5 VPN program through; you should allow it.
Step 3 - Mapping the Network Drive
- Go to the Start menu and open up “Computer” or “My Computer”
- On the
top bar, click
“Map Network Drive”
- In the
“Drive”
field,
pick a letter to represent your drive.
- The default (Z) usually works. It just needs to be a letter that your computer hasn’t named another drive already. For example, most machines have their hard drive labeled C: and a disk drive or USB thumb drive named one of the letters D-H, so those might be bad picks. But any letter from M to Z is usually un-used.
-
Copy and paste the following text into the
“Folder”
field, then press
“Finish”
:
\\multidrive.iso.mtu.edu\multidrive
- Windows security will ask for a
Username and Password. Enter
“MTU\”
in the
"Name"
slot, followed by your
Michigan Tech Username (no space between them)
- For example, if your username is "username", you would type in “MTU\username”
- Make sure that you use the correct slash mark; it’s “\” , and not “/” .
- Enter your Michigan Tech password, then press “OK”.
- Checking the box to remember your password will make the process faster in the future.
- Go to the Start Menu and click “My Computer”
- Select the Drive named “Multidrive” followed by whatever letter you picked for its name.
- This will open up your home drive with all your Michigan Tech files.
How to re-connect to your home drive after you’ve got it installed
After you log out or restart your computer, you will be disconnected from the homedrive. These steps tell you how to re-connect to your Michigan Tech files without going through the lengthy installation process again.
- Click on the "F5 Networks VPN Client" shortcut
- The firepass controller should pop up with vpn.mtu.edu already entered; click “connect”
- If vpn.mtu.edu isn’t already entered, enter it.
- Enter your Michigan Tech username and password when asked
- After that, go to the folder list on the left. Under “Network Access Controls,” select “Get an MTU address” and click the “Create” button
- Wait a short while until it reads “Status: connected” in the main window.
- Your firewall program may ask if you want to let the F5 VPN program through; you should allow it.
- Go to the Start Menu and open up “Computer” or “My Computer”
- Click on the "Multidrive" to open it.
- This will open up your home drive with all your Michigan Tech files.


Across: 7. Would he destroy tuber? (5) 8. Deserters go round nearly all Zagreb with Patrick Moore (9) 9. Throw out wild civet (5) 10. "Hold on now! That is right, soldier!" (9) 12. A French princess is wrong, Edward, is that clear? (11) 16. Composer who travels the ocean (4) 17. Terrible gaols in this city! (5) 18. Is she hurt? (4) 19. Wild bear bit Dave and was cut down! (11) 22. Impressive dog is near (9) 24. Tobias sent away a gravy maker (5) 25. Did the cleaner put him off? (9) 26. For Pat, no comeback is available (2 3) Down: 1. Fodder in front of the German is correct (9) 2. Men from the north return, carrying Rex's hose (9) 3. Porridge - and what you do to it? (4) 4. Avant garde vipers slither round giants! (11) 5. Passes workers (5) 6. Trainees go round woman's flat (5) 11. Gone off around big dry town (11) 13. OK, man (5) 14. Trace scattered particles in works (9) 15. Eliot returns to terrace in tram (9) 20. Kelvin follows Indian up here without a paddle (5) 21. Get closer to the ground around northern part of Hull (5) 23. Swivel guns performed (4)


Issues
| # | Summary | Product | Status | Kind | When |
|---|---|---|---|---|---|
| 367 |
REQUEST: Customizable hot key "slots" for user to attach scripts to |
Synergy | open | feature request | Created , updated |
| 366 |
Total non-display of any rating which is not a whole-star multiple |
Synergy | closed | bug | |
| 365 |
Support for showing/settting half-star ratings in iTunes |
Synergy | open | feature request | Created , updated |
| 364 |
Hot Key or Trigger to Display Currently Playing Track |
Synergy | closed | bug | Created , updated |
| 363 |
Synergy blasts Desktop Background Picture |
Synergy | closed | bug | Created , updated |
| 362 |
Conflict with Rogue Amoeba Airfoil |
Synergy Advance | open | bug | Created , updated |
| 361 |
REQUEST: Control track sort order when browsing via the menu |
Synergy Advance | open | feature request | Created , updated |
| 360 |
Amazon image lookup |
Synergy | closed | bug | Created , updated |
| 359 |
Typo in Tooltip for Composer checkbox-Floater Preferences |
Synergy | closed | bug | Created , updated |
| 358 |
REQUEST: Skip within track definable amount |
Synergy | closed | feature request |