search for: indivisible

Hi all, Saw on the net the wip5000 SIP wireless phone from Hitachi, a suprising rig. As anyone successfull in making it work with Asterisk? If so, how do you like it? Regards, Francois Random Thought: --------------- Molecule, n.: The ultimate, indivisible unit of matter. It is distinguished from the corpuscle, also the ultimate, indivisible unit of matter, by a closer resemblance to the atom, also the ultimate, indivisible unit of matter ... The ion differs from the molecule, the corpuscle and the atom in that it is an ion ... -- Ambrose Bierc...

...the new design > is cleaner and more expressive than before, because the "atom" model is in > some part too detailed and restrictive on how to represent data and > relations between symbols, particularly how to represent relocations. It > also lacked capability of representing indivisible memory areas having > multiple names. > > After I wrote up the first patch, I realized that the goal of the code is > somewhat similar to what the atom model aims to achieve, with some > differences. I assume that you have read the readme file for the new port. > The differences a...

...9;d even argue that the new design is cleaner and more expressive than before, because the "atom" model is in some part too detailed and restrictive on how to represent data and relations between symbols, particularly how to represent relocations. It also lacked capability of representing indivisible memory areas having multiple names. After I wrote up the first patch, I realized that the goal of the code is somewhat similar to what the atom model aims to achieve, with some differences. I assume that you have read the readme file for the new port. The differences are - An atom has only one...

...gt;> is cleaner and more expressive than before, because the "atom" model is in >> some part too detailed and restrictive on how to represent data and >> relations between symbols, particularly how to represent relocations. It >> also lacked capability of representing indivisible memory areas having >> multiple names. >> >> After I wrote up the first patch, I realized that the goal of the code is >> somewhat similar to what the atom model aims to achieve, with some >> differences. I assume that you have read the readme file for the new port. &g...

...leaner and more expressive than before, because the "atom" model is in >>> some part too detailed and restrictive on how to represent data and >>> relations between symbols, particularly how to represent relocations. It >>> also lacked capability of representing indivisible memory areas having >>> multiple names. >>> >>> After I wrote up the first patch, I realized that the goal of the code >>> is somewhat similar to what the atom model aims to achieve, with some >>> differences. I assume that you have read the readme file...

...which the linker must process. >> > > Drive by comment here: > > Other than the overhead of the section header I'm not sure what bloat > you're talking about here that the linker needs to process? The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). If an object file has a hund...

...>> of "the atom model" like SSA. LLVM IR is SSA; there is a very large amount >>> of freedom to decide on the exact design within that scope. "the atom >>> model" AFAICT just means that a core abstraction inside the linker is the >>> notion of an indivisible chunk. Our current design might need to be >>> changed, but starting from scratch only to arrive at the same basic idea >>> but now having to effectively maintain two codebases doesn't seem worth it. >>> >> >> Large part of the difficulties in development...

...>>> >> >> Drive by comment here: >> >> Other than the overhead of the section header I'm not sure what bloat >> you're talking about here that the linker needs to process? > > The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). > I'll stipulate all o...

...ing) made advanced linker features very difficult. The kinds of features Apple wanted were (and still are): dead code stripping, weak symbol coalescing, and order files (functions and data are re-ordering to minimize runtime RAM footprint). A better model is based on Atoms (nodes). An Atom is an indivisible subrange of a section. Atoms have References/Fixups (edges) to other Atoms. As Michael said, once you have your object file data in this representation, all the linker algorithms are much simpler. The hard part of linking is parsing object files into Atoms. ELF should be a little easier becau...

...gt;> >>> Drive by comment here: >>> >>> Other than the overhead of the section header I'm not sure what bloat >>> you're talking about here that the linker needs to process? >> The internal model of lld is "atom" based. Each atom is an indivisible run of bytes. A compiler generated function naturally matches that and should be an atom. The problem is that a hand written assembly code could look like it has a couple of functions, but there could be implicit dependencies (like falling through to next function). >> > I'll stipula...

...d the jump table. > > It does look like the value in @llvm.arm.space is interpreted > incorrectly if it's bigger than INT_MAX, but that's well outside its > intended range and could inevitably be used to break ConstantIslands > (the longest ARM immediate branch is 26-bits; no indivisible entity in > .text can be bigger than that). It's probably an unrelated issue. > > Also, I know I said the backend should accept any size code, but 2GB > is definitely going to trigger more edge cases than average. > > Cheers. > > Tim. > -------------- next part ------...

I have created a small ll file to reproduce the problem. I used the intrinsic function llvm.arm.space to introduce space between the beginning of the code and the jump table. If the first argument of llvm.arm.space is higher than INT_MAX ( *2147483647)*, then the bug is hit. Lower or equal to that value, it passes. It looks like a precision issue. Does this sound familiar to someone? ; ModuleID =

...nkers that use "sections"...are all things that ELF linkers already do using sections, and do not require anything finer grained than sections. Sections in ELF objects can actually be as fine-grained as you want them to be -- just as an "Atom". Doc also says, "An atom is an indivisible chunk of code or data." -- which is also what a section is for ELF. AFAICT, atoms in LLD are simply a restricted form of ELF sections: restricted to having a single symbol associated with them. It doesn't appear that they're actually enabling any new features that no other linker can...

...)" with an "AT_low_pc (<indirection into a pool of addresses> + offset)". > >> s.t. the cost of a relocation for the address is paid down the more it's used? > > Right - specifically to reduce the pool of addresses down to, ideally, one address per section/indivisible chunk of machine code (per subsection in MachO, for instance) (whereas currently there are many addresses per section) > >> How do you figure the offset out? > > Label difference - same as is done for DW_AT_high_pc today in DWARFv4 and DWARFv5 in LLVM. high_pc currently uses the l...

...o, reading data required for symbol resolution from ELF file should be satisfactory fast (I did that for COFF -- the current "atom-based ELF" linker is doing too much things in an initial load, like read all relocation tables, splitting indivisble chunk of data and connect them with "indivisible" edges, etc.) Looks like we read symbol table pretty quickly in the new implementation, and the bottleneck of it is now the time to insert symbols into the symbol hash table -- which you cannot make faster by changing object file format. Speaking of the performance, if I want to make a signif...

On Mon, Jul 29, 2013 at 9:24 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. > > From

...t change *not* passed on to title(), would you? Then what *is* changeable matter in a plot, really? The thing that I'm afraid of is that it will become a can of worms to keep track of which parameters are passed on to what routines. Not to mention the fact that the ... parameter is essentially indivisible: it is, to say the least, difficult to pass only some of the parameters. Cc-ed to R-devel. I think we need to discuss this more broadly. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen D...

Do the Digium cards have a built in CSU? Is a CSU an FCC requirement? or just a carrier requirement? TIA

I stupidly decided to save my last workspace (a large dataset) and every time I open R it loads it back in. Can I stop this? Also how do you clear variables. Thanks, Sachin --- Please consider the environment before printing this email --- Allianz - General Insurance Company of the Year 2009+ + Australia and New Zealand Insurance Industry Awards This email and any attachments has been sent by

On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > I guess, looking back at Nick's comment: > > "The atom model is a good fit for the llvm compiler model for all architectures. There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom." > > it seems that the primary issue on the