| 00:09.35 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 00:13.31 | *** join/#edev roxfan (dunno@149.78-242-81.adsl-dyn.isp.belgacom.be) |
| 00:20.36 | *** join/#edev mnemoc (~amery@shell.opensde.net) |
| 01:01.22 | NullMoogleCable | prpplague_afk |
| 01:01.23 | NullMoogleCable | :) |
| 01:01.25 | NullMoogleCable | http://www.elinux.org/Leapster |
| 01:09.05 | roxfan | arc, eh |
| 01:09.22 | roxfan | pretty uncommon cpu |
| 01:11.56 | NullMoogleCable | i have never heard of it before? |
| 01:14.07 | roxfan | http://www.arc.com/ |
| 01:15.04 | roxfan | it seems they're used in some set-top boxes |
| 01:16.09 | NullMoogleCable | yeah but how can they run flash? |
| 01:16.36 | roxfan | oh, there is an interpreter running on it, i guess |
| 01:21.55 | NullMoogleCable | http://arc-linux.sourceforge.net/ |
| 01:22.24 | NullMoogleCable | ARC itself provide an open development environment based on GNU tools environment |
| 01:22.28 | NullMoogleCable | :) |
| 01:22.38 | NullMoogleCable | that means if i read that right |
| 01:22.47 | NullMoogleCable | that the leapster runs linux |
| 01:22.57 | roxfan | doubt it |
| 01:23.33 | roxfan | although... you might be able fit it in 2mb i guess |
| 01:25.22 | NullMoogleCable | hmmm if the tools are GNU does that mean that they have to release the source? |
| 01:26.10 | roxfan | if it actually runs linux, yes |
| 01:26.24 | roxfan | but as i said, i doubt it |
| 01:37.42 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 02:37.19 | *** join/#edev SandGorgon (~OmNomNomO@75-92-29-226.war.clearwire-wmx.net) |
| 03:36.19 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 04:23.25 | *** join/#edev SandGorgon (~OmNomNomO@75-92-29-226.war.clearwire-wmx.net) |
| 04:46.26 | *** join/#edev SandGorgon (~OmNomNomO@75-92-29-226.war.clearwire-wmx.net) |
| 05:44.34 | *** join/#edev dijenerate (~dijenerat@64.210.44.37) |
| 06:13.15 | MonMotha | what is up with JTAG chains never working? |
| 06:13.37 | MonMotha | single device on the chain? always works. Chain more than one device together, good. freaking. luck. |
| 06:22.26 | MonMotha | what's amazing is that these are even both devices from the same vendor |
| 06:27.07 | *** join/#edev linac (~lin@59.56.115.66) |
| 08:49.18 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 09:05.02 | *** join/#edev linac (~lin@222.76.96.216) |
| 09:27.34 | *** join/#edev anichiest (~kvirc@207-255-143-181-dhcp.bfd.pa.atlanticbb.net) |
| 10:30.20 | *** join/#edev cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:56.33 | *** join/#edev miknix (~miknix@gentoo/developer/miknix) |
| 10:59.49 | *** join/#edev linac (~lin@124.72.230.123) |
| 12:57.12 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 13:38.35 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 13:44.50 | *** join/#edev john280z (~johnm@user-0c2h538.cable.mindspring.com) |
| 13:54.35 | *** join/#edev mbuf (~mbuf@212.226.87.141) |
| 13:55.57 | *** join/#edev insearchof_ (~insearcho@2002:ae37:8f3e:1234:eee:e6ff:fe9c:7ed) |
| 14:01.30 | *** join/#edev john280z (~johnm@user-0c2h538.cable.mindspring.com) |
| 14:09.09 | *** join/#edev elliottcable (~ec@ec2-174-129-205-205.compute-1.amazonaws.com) |
| 14:14.41 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 14:14.41 | *** mode/#edev [+o GPSFan] by ChanServ |
| 14:21.30 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 14:35.55 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 14:48.45 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 14:57.41 | *** join/#edev SpeedEvil (1000@tor/regular/SpeedEvil) |
| 15:03.55 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 15:18.07 | *** join/#edev cbx (~cbx__@unaffiliated/cbx) |
| 16:30.28 | *** join/#edev davidc__ (~davidc__@S01060002b360aacd.vc.shawcable.net) |
| 16:39.23 | *** join/#edev cbx (~cbx__@unaffiliated/cbx) |
| 17:10.46 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 17:11.01 | *** mode/#edev [+o prpplague] by ChanServ |
| 17:11.10 | prpplague | greetings earthlings |
| 17:11.16 | prpplague | ~lart landley |
| 17:11.16 | purl | hits landley with an anvil and laughs with a contralto voice ... Haha Ha HA Ha |
| 17:36.31 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 18:49.15 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 19:25.20 | *** join/#edev theDarkAura (tester@12-158-134-245.dial.bluevalley.net) |
| 19:28.43 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 19:35.34 | *** join/#edev _ABC (~me@pool-72-66-48-113.washdc.east.verizon.net) |
| 19:39.25 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 19:46.56 | rektide | man so much awesome SoC in the works |
| 19:47.07 | rektide | Marvell, Freescale, Broadcom |
| 20:11.32 | rektide | ARM: "We didn't have particularly good or dependable power-analysis tools in those days; they were all a bit approximate. We applied Victorian engineering margins, and in designing to ensure it came out under a watt, we missed, and it came out under a tenth of a watt.really low power." |
| 20:11.39 | rektide | http://queue.acm.org/detail.cfm?id=1716385 |
| 20:11.42 | rektide | ha! |
| 20:14.28 | rektide | we had a couple ethics classes in college |
| 20:14.48 | rektide | and the guy was really throwing shame all over CS / CE |
| 20:15.06 | rektide | yes, software is buggy |
| 20:15.08 | rektide | why is that? |
| 20:15.30 | rektide | well, unlike nearly every other aspect of engineering, there really arent good ways to build in tolerances |
| 20:17.50 | SpeedEvil | There has been almost no point |
| 20:17.58 | calculus | also, almost all other types of engineers have certifications/exams, but SE's don't yet they are still called engineers |
| 20:18.20 | SpeedEvil | Computers are too reliable to have gone through the effort of making programs that are robust in the face of errors. |
| 20:19.02 | SpeedEvil | If the error rate for computations was 10^-3 - then _lots_ of research would have been done into error tollerant computing and controling errors. |
| 20:19.22 | SpeedEvil | It's not - and that's spilled over into design practices for software. |
| 20:19.23 | rektide | silicon is designed to not have errors |
| 20:19.44 | rektide | the physical models of semiconductors, thats all done with very exact tolerances |
| 20:20.00 | rektide | this particular ethics lesson was more talking about software and functionality |
| 20:20.04 | rektide | higher level systems |
| 20:20.12 | roxfan | actually afaik the space-going silicon is designed with possibilty of errors |
| 20:20.32 | SpeedEvil | I'm just arguing that there has been little research into error control - due to software or hardware faults - due to the extreme reliability of hardware |
| 20:20.45 | rektide | two valid poitns |
| 20:20.54 | roxfan | what about ecc codes? |
| 20:21.09 | rektide | i'd love to see a processor that does ECC |
| 20:21.11 | SpeedEvil | ECC is at best a very simple solution. |
| 20:21.18 | roxfan | but it works |
| 20:21.26 | SpeedEvil | Doing ECC on the RAM is approximately trivial. |
| 20:21.27 | rektide | ecc protects, to my knowledge, stored memory |
| 20:21.41 | SpeedEvil | Doing ECC on computations in process is really hard |
| 20:21.54 | roxfan | rektide: there are self-correcting codes used on CDs and HDDs |
| 20:22.04 | rektide | again, stored data roxfan |
| 20:22.10 | SpeedEvil | you end up pretty much duplicating the cores and comparing results |
| 20:22.12 | rektide | for a live computational system |
| 20:22.20 | rektide | sure, you can ecc your l1 and l2 |
| 20:22.47 | rektide | what about going further? protecting the live data in the processor? as its being worked on |
| 20:22.49 | SpeedEvil | But ECCing the 3th microcode stage of multiplying 3334.343443 * 3246.38438 is _hard |
| 20:23.39 | rektide | yes |
| 20:23.47 | rektide | but |
| 20:23.50 | rektide | who knows? |
| 20:23.56 | rektide | maybe its cheaper than running a quorum of processors |
| 20:24.01 | rektide | albiet not a solved problem |
| 20:24.30 | SpeedEvil | Sure - but the research - pretty much - hasn't been done. |
| 20:24.40 | rektide | see: albiet not a solved problem |
| 20:24.42 | rektide | ;) |
| 20:25.00 | roxfan | http://www.google.com/patents?hl=en&lr=&vid=USPATAPP11623441 |
| 20:25.57 | rektide | man, that article i linked |
| 20:26.05 | rektide | it links another one talking with a pa semi guy |
| 20:26.08 | rektide | http://queue.acm.org/detail.cfm?id=957732 |
| 20:26.32 | roxfan | hmm http://www.itworld.com/hardware/68415/intels-nehalem-ex-gain-error-correction-technology |
| 20:26.44 | rektide | the untimely death of pa semi still resounds as the greatest tragedy of computer engineering in the last dozen years |
| 20:26.52 | roxfan | death? |
| 20:26.58 | rektide | destruction by apple |
| 20:27.23 | roxfan | how did they destruct them? |
| 20:27.34 | rektide | well i dont think i'll ever know |
| 20:27.48 | rektide | but pa semi had a fairly lengthy roadmap for PPC products it wanted to deliver |
| 20:28.00 | rektide | and the one product it did deliver before being bought was game changing awesome |
| 20:28.08 | rektide | an uber integrated beast of a chip |
| 20:28.37 | rektide | and apple hasnt released any products using that tech, and theres no indication they ever will |
| 20:28.53 | rektide | apple seems more interested regurgitating boring ARM designs |
| 20:32.17 | roxfan | what was that chip and what was so awesome about it? |
| 20:33.37 | rektide | steal 150 former DEC / StrongARM, Itanium, Opteron, and UltraSparc people... |
| 20:34.07 | rektide | take the ppc spec and redesign the cpu from the ground up |
| 20:34.50 | rektide | virtualized 2GHz @7watt 64 bit cores with altivec & double precision fp |
| 20:34.58 | rektide | a HUGE freaking crossbar |
| 20:35.06 | rektide | and an insane io subsystem with integrated everything. |
| 20:35.36 | rektide | raid, tcp, crypto, scsi accelerators. colossally huge ser-des pipes. |
| 20:35.56 | roxfan | 7 watt hmm |
| 20:35.57 | rektide | huge ram pipes |
| 20:36.10 | rektide | 20w for the dual core with all the io subsystem / crossbar going |
| 20:36.40 | rektide | the chip was a beast. feb 2007. |
| 20:36.53 | rektide | they had plans up to a 16 core variant |
| 20:37.26 | rektide | its one of the few "original efforts" to happen in processor tech in the past decade. |
| 20:37.46 | rektide | milsec went crazy |
| 20:38.30 | rektide | apple had to, after buying pa semi, come out and say, ok, you people who've announced plans to use the pa6t pa semi was sampling, we promise, for sake of national security, to ship parts to the public. |
| 20:40.20 | rektide | the team had an ARM license but no official announcements on what they were doing with it. its almost certain its the pa semi team that made the Apple A4 ARM cpu thats in the ipad. |
| 20:43.09 | rektide | http://queue.acm.org/detail.cfm?id=957732 |
| 20:43.11 | rektide | good reading |
| 20:43.15 | rektide | the other article was pretty mundane |
| 20:43.50 | rektide | this is actually kind of interesting; recap'ing DEC's days of pioneering semiconductors |
| 20:52.45 | rektide | (and /win 7 |
| 20:52.48 | rektide | uh my bad |
| 20:55.56 | Mirell | Hmm... |
| 21:01.38 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 21:43.57 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 22:20.20 | SpeedEvil | Of that above - 'the brain you lose about a neuron a second, and it keeps working just the same. With the variability and loss of components that we're going to see in the sub-20 nanometer technology of the very near future, we're going to have to understand how to do this tolerance stuff, how to work with chips where transistors fail and leave the game in massive numbers. At the moment, I don't think we have much idea of how to do that, except in memor |
| 22:20.24 | SpeedEvil | error control again |
| 22:36.20 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 23:15.43 | *** join/#edev prpplague (~dave123_a@ppp-70-242-112-226.dsl.rcsntx.swbell.net) |
| 23:29.59 | *** join/#edev pku (~pku@DSL01.83.171.176.125.ip-pool.NEFkom.net) |
| 23:48.25 | *** join/#edev insearchof_ (~insearcho@c-174-55-143-62.hsd1.pa.comcast.net) |