search for: fpreg

Steve Capper dixit: >> Do we need the fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregpa...

On 11/08/2013 09:12 AM, Steve Capper wrote: > + > +/* > + * x19-x28 are callee saved, also save fp, lr, sp. > + * d8-d15 are also callee saved. > + */ > + > +struct __jmp_buf { > + uint64_t __gregs[13]; > + uint64_t __fpregs[8]; > +}; > + Since the index of these arrays have no connection with what is stored in them, they should be named fields in the structure, not an array. Do we need the fpregs saved even though klibc doesn't do fp? > diff --git a/usr/klibc/arch/arm64/pipe.c b/usr/klibc/arch/arm64/p...

...asy to fix. I just don't understand this one: --snip--snip--snip-- gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=1.1 -mschedule=7100LC -DEXPORT_SYMTAB -c ksyms.c ksyms.c:247: `no_llseek' undeclared here (not in a function) ksyms.c:247: initializer element is not constant ksyms.c:247: (near initialization for `__ksymtab_no_llseek.value') --snip--snip--snip-- Uuhh... how...

Right now I'm building a 2.4.17 kernel on an HPPA Linux system. The kernel it ships with supports ext2 only. Has anybody tried ext3 on HPPA? -- Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155 Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 "A man who

...ote: > On 11/08/2013 09:12 AM, Steve Capper wrote: > > + > > +/* > > + * x19-x28 are callee saved, also save fp, lr, sp. > > + * d8-d15 are also callee saved. > > + */ > > + > > +struct __jmp_buf { > > + uint64_t __gregs[13]; > > + uint64_t __fpregs[8]; > > +}; > > + > > Since the index of these arrays have no connection with what is stored > in them, they should be named fields in the structure, not an array. > > Do we need the fpregs saved even though klibc doesn't do fp? > I agree about the named struc...

Yes, that is not an issue, but the question is if the relatively small cost of adding a bit too jmp_buf makes it worth it, as long as people understand that there is no fp support in klibc. Thorsten Glaser <tg at mirbsd.de> wrote: >Steve Capper dixit: > >>> Do we need the fpregs saved even though klibc doesn't do fp? > >>For gcc targetting Aarch64, We can only guarantee that d8-d15 are >>left alone when -mgeneral-regs-only is supplied for building klibc >>and any software linked against klibc. I would much prefer to > >We can enforce this in...

Jakob Stoklund Olesen wrote: > I have updated TableGen to support a new format for instruction selection patterns. > > Before: > > def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; > > After: > > def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; > > Since the pattern matching happens on a DAG with type labels, not

...e structs, > I guess) is a finite, fixed-size sequence of bits; nonetheless, we have direct support > for representing pointers, vectors, FP, and so on, when we could absolutely instead > use an appropriately-sized integer type, a large collection of intrinsics, and some sort > of "fpreg" attribute on call arguments to mark the difference in CCs. > > In general, I think LLVM has gotten way too addicted to the pretense that adding things > as intrinsics or funky instruction attributes isn't adding just as much complexity as adding > new types and instructions....

I have updated TableGen to support a new format for instruction selection patterns. Before: def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; After: def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input

....0.1/tools/ioemu-dir/target-i386/kvm.c:301: error: ‘CPUX86State’ has no member named ‘fpuc’ /usr/src/xen-4.0.1/tools/ioemu-dir/target-i386/kvm.c:303: error: ‘CPUX86State’ has no member named ‘fptags’ /usr/src/xen-4.0.1/tools/ioemu-dir/target-i386/kvm.c:304: error: ‘CPUX86State’ has no member named ‘fpregs’ /usr/src/xen-4.0.1/tools/ioemu-dir/target-i386/kvm.c:304: error: ‘CPUX86State’ has no member named ‘fpregs’ /usr/src/xen-4.0.1/tools/ioemu-dir/target-i386/kvm.c:305: error: ‘CPUX86State’ has no member named ‘xmm_regs’ /usr/src/xen-4.0.1/tools/ioemu-dir/target-i386/kvm.c:305: error: ‘CPUX86State’...

Hi all, On behalf of Andes Technology Corp, I am proposing a backend targeting the NDS32 V3 ISA. NDS32 V3 ISA is a 16/32 bit mixed instruction set architecture that developed By AndesTech. You can find more information at the Andes website <http://www.andestech.com/>, and reference AndeStar ISA Manual (V3 ISA) from document download page <http://www.andestech.com/product.php?cls=9>.

We would like to discuss the possibility of adding support for fixed point operations, either through new types, instructions, or intrinsics. This is an extension to a previous proposal (http://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html) for implementing fixed point arithmetic entirely in clang, but John McCall brings up good points in the comments thread of

Hello, This series introduces arm64 support to klibc. I've rebased the work from Neil Williams and Anil Singhar into the following three patches. Most of the code changes are due to new syscall implementations being needed for arm64 as a only a minimal set of syscalls are defined in the arm64 kernel. This series is to be applied against the latest klibc, just after 25a66fa README.klibc: