similar to: [LLVMdev] mips inline assembly

On 02/17/2013 01:08 PM, Andrew Trick wrote: > > On Feb 17, 2013, at 1:01 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > >> On 02/17/2013 12:48 PM, Andrew Trick wrote: >>> On Feb 16, 2013, at 1:31 PM, Cameron Zwarich<zwarich at apple.com> wrote: >>> >>>> That's exactly the right place.

On Feb 17, 2013, at 1:01 PM, Reed Kotler <rkotler at mips.com> wrote: > On 02/17/2013 12:48 PM, Andrew Trick wrote: >> On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> That's exactly the right place. >> Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's

> For those doing new ports, you might be interested to study how I did the td > files for mips16. There is still some cleanup I will do but essentially I > have cleanly layered the abstraction into four layers: > 1) machine formats > 2) assembly syntax > 3) instructions (none with patterns) > 4) patterns. Maybe you could write a bit more in-depth about this?

Right now inline assembler just passes through to the assembler if there is no direct object emitter. If there is a direct object emitter, it gets processed in Asm parser and MC instructions are produced. I propose that the initial parsing happen very early and the inline assembly code be replaced with a sequence of MachineInstructions in the basic block where it occurs. Then code like

On 02/17/2013 12:48 PM, Andrew Trick wrote: > On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> That's exactly the right place. > Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's as if they're real instructions? You don't want to schedule or register allocate the real

Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be

My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done.

Sounds like bundles will be the simplest to start with though I suppose I could just lower the pseudos after scheduling is done; for now. Bundles will prevent things from being able to be scheduled in more creative ways but for that I need to think more about the problem. So I can just create a bundle, insert instructions in it, and all will work more or less? I'm trying to take the next

Geting a seg fault. Have not investigted the cause. rkotler at mipsswbrd002:~/richard$ tar vfxz ~/Downloads/ellcc-mips-linux-2014-Mar-24-07-32-26.tgz rkotler at mipsswbrd002:~/richard/ellcc/bin$ gdb ./ecc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are

The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. On 09/05/2012 08:28 PM, Jim Grosbach wrote: > The instructions are defined by their encodings, not the assembly syntax. You want

The instructions are defined by their encodings, not the assembly syntax. You want separate instruction definitions for the different encodings and select. Between them in the assembler via sub target features. See ARM handling of thumb vs thumb2 vs arm for examples of how to do this. On Sep 5, 2012, at 6:59 PM, reed kotler <rkotler at mips.com> wrote: > The micro mips processor

I have run "make check", the "test-suite" on x86 and all internal mips flavors with this patch and no problems arose. On 11/04/2012 11:07 AM, Reed Kotler wrote: > The main idea is to distinguish between emitting normal labels and debug > labels. This is the nomenclature chosen by the gcc people working on > this same problem. > > I have just added one

On 01/29/2014 12:14 PM, Rafael Espíndola wrote: > On 28 January 2014 19:56, reed kotler <rkotler at mips.com> wrote: >> I would like to make the following member of AsmPrinter be protected >> >> >> void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, >> InlineAsm::AsmDialect AsmDialect = >>

Great Job! If I use alternate-clang-driver, will I need mips-gcc still? I mean alternate-clang-driver use as&ld directly or by calling gcc? Regards, Jia Liu On Tue, Feb 28, 2012 at 10:39 AM, reed kotler <rkotler at mips.com> wrote: > There is also: > > 1) an alternate clang driver at > http://code.google.com/p/alternate-clang-driver/ . This makes > it more or less gcc

On Sat, Aug 24, 2013 at 2:15 AM, Reed Kotler <rkotler at mips.com> wrote: > Hi Jun, > > Are you using the Mips compiler or working on it? > > yes, i am looking at its code to understand this architecture. thanks. Jun > > On 08/22/2013 11:12 PM, Jun Koi wrote: > >> hi, >> >> there are two arrays named DecoderTable32[] and DecoderTable16[] that

We are considering running clang format on the whole Mips target. Is there any rule against this? Is there any good argument against doing this even if there is no rule against it? TIA. Reed

I have pushed almost all the changes for the mips16 port and it passes about 90% of the single source tests from test-suite. It is still an experimental port but I am working hard to finish up the last details as soon as possible. Some things that are incomplete: 1) It is using soft float at this time. I did not like the gcc mips16 floating point design and will do something much better for

The micro mips processor assembly language is basically 100% the same as mips32/mips64. There are some assembler directives you add but for a base port, but that is all you need to do. However, the binary instruction encoding is entirely different. There are a combination of 16 and 32 bit instruction encodings. The question is, what's the best way to handle this? Extending tablegen ?

On 01/28/2014 06:29 PM, Eric Christopher wrote: > Uhhhh... > > -eric > > On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >> I would like to make the following member of AsmPrinter be protected >> >> >> void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, >> InlineAsm::AsmDialect

We are currently working on the direct object emitter for the Mips compiler. When we need to emit a branch instruction to a forward label, how is that done? In an assembler this would normally be done in a second pass. TIA. Reed