| 01:13.23 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 01:24.33 | *** join/#edev NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
| 01:24.34 | *** join/#edev prpplague (~prpplague@ppp-70-249-149-148.dsl.rcsntx.swbell.net) |
| 01:35.35 | *** join/#edev RobotGuy (~n7pkt@c-24-21-60-36.hsd1.or.comcast.net) |
| 01:51.24 | *** join/#edev NullMoogleCable (~fake@cpe-69-205-123-203.rochester.res.rr.com) |
| 01:52.08 | *** join/#edev landley (~landley@adsl-99-24-57-198.dsl.aus2tx.sbcglobal.net) |
| 01:52.08 | *** mode/#edev [+o landley] by ChanServ |
| 01:52.24 | landley | Apparently I'm going to Scale tomorrow. |
| 01:52.44 | landley | I got informed this morning that work wanted me there. *shrug* |
| 01:53.04 | landley | I vaguely recall that either prpplague or solar were going to be there? |
| 01:53.44 | prpplague | not i |
| 01:53.53 | prpplague | tries to avoid going to california |
| 01:55.25 | landley | I can't seem to avoid it, but I get reimbursed and get frequent flyer miles, so can't really complain... |
| 01:59.03 | prpplague | i don't even consider going to a conference in the US unless i have to |
| 02:48.44 | dalias | hi |
| 03:10.50 | calculus | ahh, just missed him |
| 03:11.06 | calculus | well, I am going to SCALE |
| 03:16.13 | dalias | :/ |
| 03:16.23 | dalias | any arm asm coders here? |
| 03:16.43 | dalias | i'm looking for someone to do the arm port for musl |
| 03:18.47 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 03:18.47 | *** mode/#edev [+o GPSFan] by ChanServ |
| 03:19.34 | dalias | maybe i should just lookup stuff myself and write the port with nowhere to test it :) |
| 03:24.15 | *** join/#edev rasker (~Rehan@89-168-90-13.dynamic.dsl.as9105.com) |
| 04:03.08 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 04:28.50 | *** join/#edev NullMoogleCable (~fake@cpe-69-205-123-203.rochester.res.rr.com) |
| 05:06.37 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-rbkaoykwwyuctjpv) |
| 05:10.51 | *** join/#edev dalias (dalias@216-12-86-13.cv.mvl.ntelos.net) |
| 05:48.45 | *** join/#edev NightMonkey (debian-tor@pdpc/supporter/professional/nightmonkey) |
| 09:15.40 | *** join/#edev kosiini (~janne@pdpc/supporter/student/kosiini) |
| 09:36.30 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 09:36.30 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 10:14.23 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 10:21.21 | *** join/#edev risca (~risca@nl-152-163.netlogon.liu.se) |
| 11:08.43 | *** join/#edev avinashhm (~avinash-h@203.101.61.7) |
| 11:35.25 | *** join/#edev gustavoz (~gustavoz@host231.186-109-10.telecom.net.ar) |
| 12:26.03 | *** join/#edev madsy_ (~madsy@fu/coder/madsy) |
| 14:24.10 | *** join/#edev gustavoz (~gustavoz@host127.190-229-71.telecom.net.ar) |
| 14:27.47 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-sgaztydlvhexjtfk) |
| 14:43.32 | *** join/#edev RobotGuy (~n7pkt@c-24-21-60-36.hsd1.or.comcast.net) |
| 15:06.00 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-fef8de00-126.dhcp.inet.fi) |
| 15:17.15 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 15:17.15 | *** mode/#edev [+o GPSFan] by ChanServ |
| 15:30.53 | RobotGuy | chouimat, GPSFan, G'Morning |
| 15:31.10 | GPSFan | RobotGuy, howdy... |
| 15:31.38 | chouimat | morning |
| 15:32.54 | kergoth` | morning guys |
| 15:32.56 | chouimat | looks at the android buildsystem and cries |
| 15:33.00 | chouimat | kergoth`: hey |
| 15:33.21 | RobotGuy | Are there any free integrated (IDE and Toolchain) tools for ARM7 under Linux? |
| 15:33.57 | RobotGuy | chouimat: I try not to look at build systems because they almost always make me cry. |
| 15:35.18 | chouimat | RobotGuy: it's for a potential contract ... |
| 15:35.38 | RobotGuy | chouimat: Ahhhhh, OK. |
| 15:36.37 | chouimat | RobotGuy: I have built the current firmware for them, but it seems some of their customers want to have android on it, not linux ... go figures ;) |
| 15:37.30 | chouimat | cool my pandaboard is on his way ... should have it before noon :) |
| 15:37.45 | RobotGuy | I've installed the Android dev tools and built helloworld, but haven't done more. |
| 15:38.31 | RobotGuy | chouimat: I like the idea of PandaBoard, but my partner sent his right back after looking at it. Are there issues that would cause that kind of reaction from a knowledgable person? |
| 15:38.50 | chouimat | don't know |
| 15:39.43 | wmat | RobotGuy: what struck your partner about the Pandaboard to invoke the return? |
| 15:40.19 | RobotGuy | wmat: He didn't even bother to power it up. It was the way the board looked. He said it was crap. |
| 15:41.24 | RobotGuy | We've been developing an expansion for BeagleBoard-xM. |
| 15:42.50 | RobotGuy | wmat: That's a pretty extreme reaction from a person who knows his stuff when it comes to designing boards and such. |
| 15:44.40 | *** join/#edev jonmasters (~jcm@edison.jonmasters.org) |
| 15:46.29 | RobotGuy | wmat: That and prpplague's suggestion I stay with BeagleBoard has really put me off from trying out a PandaBoard even though I really like the feature set. |
| 15:46.46 | wmat | RobotGuy: the reaction sounds irrational |
| 15:47.11 | wmat | but, everyone is entitled to their opinions |
| 15:47.27 | RobotGuy | wmat: I wonder. It doesn't make sense to discard a board based on just looks. |
| 15:47.51 | wmat | agreed |
| 15:48.18 | RobotGuy | I'd still like to try out a PandaBoard, but can't afford to waste $174.00 on something I can't work with. |
| 15:48.52 | wmat | your partner should have just given you his |
| 15:48.52 | RobotGuy | I really enjoy working with BeagleBoard-xM. |
| 15:49.11 | RobotGuy | wmat: I would have happily accepted it and given it a new home. :) |
| 15:50.22 | RobotGuy | I look at PandaBoard based on features and see what it has I want, and it has quite a lot. Then I start looking at development tools for it. |
| 16:52.16 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-svvndxslqzzxzaoj) |
| 16:52.46 | Mirell | Oh, sexy Light Peak on the Macs now |
| 17:10.20 | *** join/#edev prpplague (~danders@nat/ti/x-spwgyplypmxjphut) |
| 17:11.00 | *** mode/#edev [+o prpplague] by ChanServ |
| 17:35.14 | *** join/#edev risca (~risca@nl-152-163.netlogon.liu.se) |
| 18:20.54 | *** join/#edev MonMotha (~monmotha@adsl-99-130-204-213.dsl.ipltin.sbcglobal.net) |
| 18:34.23 | *** join/#edev ZeZu (~ZeZu@c-98-227-57-1.hsd1.in.comcast.net) |
| 19:03.50 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-spirbdjbedlwvjgr) |
| 19:30.29 | *** join/#edev keesj (~keesj@ip49-193-210-87.adsl2.static.versatel.nl) |
| 19:37.00 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 19:40.02 | *** join/#edev jnd (~jenda@unaffiliated/jnd) |
| 20:02.15 | *** join/#edev gustavoz (~gustavoz@host127.190-229-71.telecom.net.ar) |
| 20:03.54 | *** join/#edev wmat (~btraynor@gromit.mixdown.ca) |
| 20:05.06 | *** join/#edev risca (~risca@c-824172d5.04-191-6e6b701.cust.bredbandsbolaget.se) |
| 20:31.08 | *** join/#edev dfarnsworth (~dfarnswor@nat/montavista/x-jeytwszgassstzoz) |
| 20:34.32 | *** join/#edev solar (~solar@smtp.gentoo.org) |
| 20:41.17 | *** join/#edev Crofton|work (~balister@pool-74-107-167-114.ronkva.east.verizon.net) |
| 20:42.42 | *** join/#edev mpk (mp@aggr.com) |
| 20:43.54 | *** join/#edev krushia (~krushia@h69-131-92-179.cntcnh.dsl.dynamic.tds.net) |
| 21:00.30 | *** join/#edev NullMoogleCable (~fake@cpe-69-205-123-203.rochester.res.rr.com) |
| 21:05.53 | *** join/#edev MonMotha (~monmotha@108-71-210-59.lightspeed.iplsin.sbcglobal.net) |
| 21:10.38 | *** join/#edev roxfan (dunno@91.180.198.220) |
| 21:25.05 | *** join/#edev gandhijee (akp@ip67-152-15-148.z15-152-67.customer.algx.net) |
| 21:36.50 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 21:41.16 | *** join/#edev florian (~fuchs@sign-4db6a124.pool.mediaWays.net) |
| 21:41.16 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 21:42.44 | *** join/#edev MonMotha (~monmotha@108-71-210-59.lightspeed.iplsin.sbcglobal.net) |
| 22:40.50 | *** join/#edev MonMotha (~monmotha@2002:6c47:d23b:1:224:7eff:fedc:893e) |
| 22:42.23 | MonMotha | holy IPv6 batman |
| 22:44.18 | dalias | any arm asm coders here? |
| 22:47.55 | roxfan | doing a survey? |
| 22:49.26 | dalias | :) |
| 22:50.14 | dalias | well i'm looking for either someone who can recommend a quick guide to arm asm for someone who knows asm but just not arm,.. |
| 22:50.41 | dalias | or who'd be interested in directly helping port musl (www.etalabs.net/musl) to arm |
| 22:50.46 | MonMotha | google for the arm quickref card |
| 22:51.07 | roxfan | http://infocenter.arm.com/help/topic/com.arm.doc.dui0204j/index.html this one isn't bad |
| 22:51.22 | MonMotha | other than, it's a predicated, largely orthogonal instruction set, no unaligned accesses allowed, and lots of operations can have a "free" bit shift |
| 22:51.29 | roxfan | though it's naturally biased to ARM tools |
| 22:52.23 | roxfan | dalias: i can help you with specific issues, but i don't have time to do the porting myself |
| 22:53.33 | roxfan | http://infocenter.arm.com/help/topic/com.arm.doc.dui0204j/DUI0204J_rvct_assembler_guide.pdf <- pdf ver |
| 22:54.34 | dalias | are calls and jumps performed by arithmetic on the PC register? (r15 iirc) |
| 22:54.43 | roxfan | they can be |
| 22:54.53 | dalias | i couldn't find a dedicated call instruction |
| 22:55.13 | roxfan | well, calls are a bit peculiar |
| 22:55.28 | roxfan | arm doesn't use stack to store return addresses |
| 22:55.49 | roxfan | by convention, the return address is placed into LR |
| 22:55.49 | dalias | well surely it does, implicitly, for more than one level of call :) |
| 22:56.05 | dalias | i.e. a function needs to save LR on the stack or in a call-saved register before making a call |
| 22:56.08 | roxfan | which can be saved onto stack if further calls are necessary |
| 22:56.53 | dalias | thankfully there are only a few things i need to implement in asm |
| 22:57.10 | roxfan | originally calls were done with explicit LR save |
| 22:57.14 | dalias | atomic memory ops, which will mostly be a jump into the linux-provided 0xffff???? code |
| 22:57.26 | roxfan | but now there is BL and BXL |
| 22:58.02 | roxfan | BL=branch and link, "link" meaning "save return address into LR" |
| 22:58.12 | dalias | startup code (for taking control after execve and starting main) |
| 22:58.38 | dalias | and some pthread-related stuff (the "worst" is a function that unmaps its own stack and terminates the thread :) |
| 23:00.24 | dalias | hmm, i see branch instructions only have up to 32mb offset |
| 23:00.26 | dalias | how is that handled? |
| 23:00.54 | roxfan | if you need bigger range, use a register |
| 23:01.22 | dalias | is it possible to do relative branches (required for PIC) with a register? |
| 23:01.32 | roxfan | well, not directly |
| 23:01.58 | roxfan | you'd have to add PC to the delta first |
| 23:02.00 | dalias | something like load [dest-.] and then add that value to PC |
| 23:02.26 | dalias | btw what does gcc generate? |
| 23:02.43 | dalias | it seems like gcc would not be happy assuming functions will always be within 32 mb.. |
| 23:03.40 | roxfan | for PLT entries two adds and a load to PC are used |
| 23:04.24 | dalias | and for non-PLT calls (calls within the same DSO or the main program) it just assumes they fit in 32 megs? |
| 23:04.51 | MonMotha | is linker relaxation supported on ARM? |
| 23:05.27 | dalias | it's good asking about this kinda stuff now because i'm designing/implementing the dynamic linker right now too |
| 23:05.30 | dalias | :) |
| 23:06.04 | roxfan | i _think_ linker is supposed to generate veneers for code that's out of range but i'm not 100% sure |
| 23:06.17 | dalias | ah that makes sense |
| 23:06.36 | dalias | basically the linker would generate a stub that loads the full address and jumps to it |
| 23:06.42 | dalias | and put the stub within 32 megs |
| 23:06.51 | roxfan | did you get eabi docs yet? |
| 23:07.06 | dalias | no, i hear about it a lot on uclibc lists tho |
| 23:07.18 | roxfan | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html |
| 23:07.19 | dalias | what is eabi? is it an alternative to some traditional abi? |
| 23:07.39 | roxfan | [arm] embedded abi |
| 23:07.54 | MonMotha | contrast with OABI |
| 23:10.17 | roxfan | start with bpabi and aaelf |
| 23:31.05 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 23:33.55 | dalias | does arm have single-precision float hardware support always? |
| 23:34.57 | roxfan | no |
| 23:35.37 | roxfan | low-end chips (e.g. ARM7, Cortex-M) don't have FPU |
| 23:41.22 | dalias | how is it handled? |
| 23:41.36 | roxfan | mm, what do you mean? |
| 23:41.58 | dalias | e.g. how are floating point args and return values passed? |
| 23:42.21 | dalias | on the stack? in integer registers? |
| 23:42.29 | roxfan | there are two options |
| 23:42.57 | roxfan | soft-float: floats are passed in GPRs, same as integers |
| 23:43.28 | roxfan | hard-float: floats are passed in FPU registers (naturally, this requires an FPU) |
| 23:46.02 | roxfan | see AAPCS (hard-float is called "VFP variant" in it) |
| 23:47.36 | MonMotha | I was of the impression that almost all ARMs lacked any form of FPU/VFP, not just the small ones. |
| 23:48.02 | MonMotha | there are FPU/VFP standards, but implementations were rare last I checked |
| 23:48.16 | roxfan | it's pretty much standard beginning from ARM9 |
| 23:48.59 | MonMotha | hum, did the 926EJ-S have it? |
| 23:49.02 | MonMotha | I didn't think it did |
| 23:49.14 | roxfan | well yeah not that one |
| 23:49.18 | MonMotha | ah, ok |
| 23:49.21 | MonMotha | it was very popular :) |
| 23:49.50 | roxfan | but i'm not sure there were many VPF-less ARM11s, if any |
| 23:49.58 | dalias | so does the eabi use pass-by-GPR? |
| 23:50.01 | roxfan | and it's mandatory in Cortex-A |
| 23:50.11 | roxfan | dalias: it can use either |
| 23:50.22 | dalias | hardly sounds like an ABI then :) |
| 23:50.46 | roxfan | an elf file can include tags which tell which one it expects |
| 23:50.46 | MonMotha | well, float style is an ABI option |
| 23:51.03 | MonMotha | hard float is always OK, but it'll be slow unless the hardware actually has the FPU |
| 23:51.30 | MonMotha | soft float is faster on FPU-less CPUs, but slower than hardware on ones so equipped, and everybody has to agree on soft-float |
| 23:51.46 | MonMotha | (of course, if a called proc is expecting soft float and you pass hard float, that's bad too) |
| 23:52.06 | roxfan | http://wiki.debian.org/ArmEabiPort#ARMfloatingpoints |
| 23:52.07 | MonMotha | IIRC, you can use the soft float ABI with hard float CPU instructions |
| 23:52.15 | MonMotha | it's just up to the callee to move the data around |
| 23:52.31 | MonMotha | anyway, I need to get going |
| 23:52.35 | dalias | that rather makes sense to me... |
| 23:55.51 | roxfan | btw if you plan to target iOS, be aware they don't use EABI |
| 23:55.56 | roxfan | e.g. int64s are not aligned to an even register |
| 23:59.18 | roxfan | oh btw this might be interesting to you: http://www.codesourcery.com/sgpp/lite/arm/portal/kbentry39 |