| 00:00.18 | *** join/#gsoc dagar (n=dagar@206-248-137-66.dsl.teksavvy.com) |
| 00:02.50 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 00:22.47 | *** join/#gsoc DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 00:37.58 | *** join/#gsoc Greywhind (n=Greywhin@ip70-176-166-219.ph.ph.cox.net) |
| 01:32.49 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 01:38.31 | *** join/#gsoc cjm1313 (n=cjm1313@ppp-71-142-0-99.dsl.irvnca.pacbell.net) |
| 01:40.19 | *** join/#gsoc chintan_irc (n=chintan@59.92.245.17) |
| 01:42.52 | cjm1313 | Hello, I just finished my first semester at a community college and am planning on transferring with a Computer Science major. The Summer of Code sounds interesting to me and I was wondering if it would be feasible to go next summer and what I would need to do to prepare. So far all I've learned is a little VB.NET the basics of object oriented design in C++. |
| 01:43.20 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 01:43.22 | thiago | language is not the matter |
| 01:43.27 | thiago | you need to find something to do |
| 01:43.49 | thiago | take a look at this years' list of organisation and see if there's anything that you like. Take a look at the orgs' list of ideas and list of projects. |
| 01:44.06 | thiago | then start getting involved with the communities now (not in March) |
| 01:45.49 | MatthewWilkes | cjm1313: thiago is right, if the people in a community know you and know you're serious about getting involved they're much more likely to select you |
| 01:46.32 | cjm1313 | So I should find a project that interests me, and contact that organization? |
| 01:47.12 | cjm1313 | By communities you mean the mentoring organizations? |
| 01:47.49 | thiago | no, I mean the open source communities |
| 01:48.03 | thiago | forget mentoring organisations at this point, since we don't know who will be selected for next year |
| 01:48.25 | Ori_B | cjm1313: mentoring organizations aren't usually an entity you'd interact with. |
| 01:48.41 | cjm1313 | Communities like sourceforge? |
| 01:48.57 | Ori_B | cjm1313: communities like the people who are working on the projects you're interested in. |
| 01:52.28 | cjm1313 | Do I find a project sponsored by one of the mentoring programs last year and contact the people working on it? Where is a good place to find info on open source projects? |
| 01:52.51 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 01:52.54 | thiago | no |
| 01:53.04 | thiago | you look at the projects that were accepted, the ones that weren't, etc. |
| 01:53.13 | thiago | then you find something you like and start contributing to that community |
| 01:53.19 | thiago | forget GSoC at this point |
| 01:55.06 | cjm1313 | Ok. You mean the projects here, though? Or elsewhere. http://code.google.com/soc/2008/ |
| 01:55.12 | thiago | yes, those |
| 01:56.46 | cjm1313 | So just find a project that interests me and contact them about contributing? |
| 01:56.57 | thiago | yes |
| 01:57.01 | thiago | and do start contributing |
| 01:57.14 | cjm1313 | All right. Thank you. |
| 01:57.16 | thiago | the more you get involved and prove yourself worthy, the more likely it is to get selected |
| 01:57.24 | thiago | you'll also need to have a good project idea for next year |
| 01:58.08 | cjm1313 | So if I went next year would I go with whatever community I am already working with? |
| 01:58.51 | thiago | you're more likely to get selected by a community that knows you already |
| 01:59.08 | thiago | but sending to a few more might also be a good idea to hedge your bets |
| 02:00.14 | cjm1313 | Oh. So if the community I am in has a presence at the SoC they could select me. |
| 02:00.25 | thiago | yes |
| 02:01.30 | *** join/#gsoc lyaunzbe (n=lyaunzbe@142.131.89.82) |
| 02:01.45 | cjm1313 | Would it be a big deal joining a community/project based in a language I'm not familiar with? Is there all that much I could contribute? I've hardly scratched the surface with C++ |
| 02:02.54 | MatthewWilkes | cjm1313: You won't get much hand-holding, so it depends on how good an independenant learner you are |
| 02:02.56 | danderson | well, your project has to be writing code, so it's better if you don't end up spending 3 months trying to learn the language :) |
| 02:02.56 | thiago | well, if you expect to be selected for a three-month coding work in a given language, you had better know how to use it |
| 02:02.58 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 02:06.31 | cjm1313 | All right. I know where to start at least. Is there anything else I should know? |
| 02:07.10 | MatthewWilkes | Yes, one more thing.. You must find the jade monkey before the next full moon. |
| 02:07.55 | MatthewWilkes | j/k |
| 02:07.56 | danderson | ah, yes, very important. |
| 02:08.06 | cjm1313 | I've got a couple weeks then |
| 02:08.07 | cjm1313 | :P |
| 02:08.48 | cjm1313 | Thanks for the answering my questions again. |
| 02:09.02 | cjm1313 | open source ftw! |
| 02:13.00 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 02:14.04 | MatthewWilkes | anyway, danderson! thiago! Having a good christmas? |
| 02:17.25 | danderson | MatthewWilkes: I'm implementing an m68k cpu generator, first in python, now in lisp |
| 02:17.28 | danderson | so, yeah :D |
| 02:22.34 | MatthewWilkes | nice |
| 02:22.38 | MatthewWilkes | lisp, though? |
| 02:22.51 | *** join/#gsoc thiagoss (n=thiagoss@189.71.62.94) |
| 02:23.05 | MatthewWilkes | has nightmares about emacs integration |
| 02:23.48 | *** join/#gsoc tcoppi (n=nuclear@rainbow.nmt.edu) |
| 02:28.21 | *** join/#gsoc bgola_ (n=Bruno@189.100.154.242) |
| 02:33.56 | Ori_B | merry christmas. |
| 02:34.02 | Ori_B | danderson: hm, cpu generator? |
| 02:34.10 | Ori_B | emulator, you mean? |
| 02:35.05 | danderson | nope :o) |
| 02:35.14 | danderson | the thought progression was: |
| 02:35.19 | danderson | - I just got a G1 phone |
| 02:35.27 | danderson | - I want a Genesis emulator for Android |
| 02:35.41 | danderson | - The Genesis has a 68k CPU, but no 68k emulator exists in Java |
| 02:35.57 | danderson | - Writing this by hand is going to be pain, there are 53 operand variants of 'ADD' alone |
| 02:36.17 | danderson | - I'll write a generator that takes a high level description of the assembler language, and will generate the emulator code from there |
| 02:36.20 | danderson | :) |
| 02:37.11 | Ori_B | ahh. |
| 02:37.17 | danderson | it's interesting to note that Generator, one of the nicer Genesis emulators for normal computers, also uses this approach (in fact, it inspired me). |
| 02:37.21 | Ori_B | so an emulator generator |
| 02:37.26 | danderson | it uses it in an insane and undocumented way, of course |
| 02:37.27 | Ori_B | cool. |
| 02:37.28 | danderson | yeah |
| 02:37.47 | danderson | I started in Python, but I've just started prattling around with doing it in common lisp instead |
| 02:37.50 | Ori_B | is planning to play around with that approach for writing an x86 assembler soon |
| 02:37.53 | danderson | I mean, basically this is a compiler |
| 02:38.00 | danderson | and lisp wins when you need to manipulate code as data |
| 02:38.13 | Ori_B | especially since I ran across an XML description of all x86 instructions a few days ago. |
| 02:38.17 | danderson | so in lisp, my plan would be to first compile the assembler definition to an AST |
| 02:38.24 | danderson | then write a Java code generator to translate the AST |
| 02:38.38 | Ori_B | yep. |
| 02:39.05 | danderson | and, one day, when a native SDK comes out for Android, I can just rewrite the translator and output either C, or even directly ARM assembler. |
| 02:39.34 | Ori_B | mhm |
| 02:39.36 | danderson | and hopefully this will make me level up in ubergeekery |
| 02:39.44 | *** join/#gsoc RT|Chatzilla (n=rt@reactos/tester/RT) |
| 02:40.01 | Ori_B | hehe |
| 02:40.25 | danderson | my friends have all been looking at me funny since I explained what I'm trying to do :( |
| 02:40.51 | Ori_B | ...your friends aren't all that geeky, are they? |
| 02:40.53 | thebolt|away | danderson: sounds about the same as what cgen is doing (but they use Scheme instead of CL) |
| 02:40.53 | Ori_B | :P |
| 02:41.35 | danderson | thebolt|away: aaw crud, you had to go and ruin my fun :( |
| 02:41.47 | Ori_B | danderson: now, if you tried to do something like HP's Dynamo optimizer, that would be neat |
| 02:41.54 | danderson | this just confirms my theory that everything that's ever been thought of has been implemented. |
| 02:42.16 | thebolt|away | danderson: well, their purpose is for compiler (or well, assembler/backend) generation .. |
| 02:42.20 | danderson | thebolt|away: thanks though, looks like a cool project (and also possibly an inspiration for code structure) |
| 02:42.33 | *** join/#gsoc DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 02:42.43 | Ori_B | gets back to messing around with writing his compiler/language |
| 02:42.59 | danderson | thebolt|away: seems like it also generates a simulator |
| 02:43.02 | Ori_B | it'll be interesting trying to figure out efficient closures in an unmanaged language |
| 02:43.05 | danderson | which isn't too far from an emulator |
| 02:43.18 | danderson | though their descriptions are probably way too specific for me in that case |
| 02:43.25 | danderson | eg. timing information etc. |
| 02:43.48 | thebolt|away | danderson: well, maybe you can use their CPU descriptions anyhow, just ignore extra data |
| 02:44.15 | thebolt|away | (and add "translation"/interpretation info to it) |
| 02:44.29 | danderson | yup |
| 02:44.32 | danderson | looking into it now |
| 02:45.33 | Ori_B | hm... *thinks* |
| 02:45.51 | Ori_B | for extra fun: make the closures C-funcpointer compatible! |
| 02:46.41 | Ori_B | (GCC almost supports this as a C extension, but it's not usable; can't return closures from functions. breaks if you do) |
| 02:46.51 | danderson | what? |
| 02:48.24 | MatthewWilkes | .oO(Use Python) |
| 02:48.44 | Ori_B | danderson: I'm playing with writing a new programming language. |
| 02:49.06 | Ori_B | I'd like it to support closures, and ideally I'd also like it to be ABI compatible with C |
| 02:49.20 | danderson | ah. |
| 02:49.29 | danderson | that's one urge I haven't had yet |
| 02:49.35 | danderson | a general purpose language that is |
| 02:49.45 | danderson | DSLs are nice for various applications, but it's not the same challenge |
| 02:49.55 | danderson | making an internally consistent general purpose language is hard |
| 02:50.32 | Ori_B | true. |
| 02:50.50 | Ori_B | so far I've more or less settled on a syntax/feel for it |
| 02:52.37 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 02:56.20 | Ori_B | it's also a fun project :) |
| 02:57.52 | danderson | thebolt|away: isn't that project lying a bit? |
| 02:58.01 | danderson | I see only implementations for hopelessly obscure CPUs |
| 02:58.04 | danderson | nothing mainstream |
| 02:58.21 | danderson | hmm, nope. |
| 02:58.26 | danderson | Looks like cvs fucked up the checkout. |
| 02:58.30 | danderson | shakes fist at cvs |
| 03:00.08 | Ori_B | hehe |
| 03:00.13 | danderson | holy crap on a cracker, this language is good... |
| 03:00.57 | Ori_B | looks |
| 03:01.18 | *** join/#gsoc L4m3r (n=L4m3r@bzflag/developer/L4m3r) |
| 03:01.20 | danderson | not that I understand any of it |
| 03:01.31 | danderson | looking at the arm7 definition, hoping the RISC arch would help |
| 03:01.33 | danderson | well, it doesn't |
| 03:01.38 | danderson | in case you were wondering |
| 03:02.59 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 03:03.42 | Ori_B | yeah. the arbitrary numbers are somewhat unhelpful. |
| 03:04.40 | danderson | I guess they thought it was obvious :) |
| 03:05.31 | Ori_B | heh |
| 03:05.37 | Ori_B | it gets more readable as you go farther down |
| 03:06.52 | danderson | only vaguely afaict |
| 03:07.05 | danderson | and I'm not clear on how it derives the actual instruction encoding from those defs |
| 03:08.38 | Ori_B | I'm guessing that some of the magic numbers are for that |
| 03:08.45 | danderson | yeah |
| 03:08.59 | danderson | looks like bit-offset and bit-size in the def |
| 03:09.10 | danderson | so from there, given all the components of an instruction, it can reconstruct the encoding |
| 03:09.21 | Ori_B | yep. |
| 03:09.23 | danderson | how it figures out a corresponding decoder, frankly, feels like magic |
| 03:09.40 | danderson | (generic decode-and-dispatch I mean) |
| 03:09.43 | Ori_B | hm? what do you mean? |
| 03:09.59 | danderson | well, once you've defined all the instructions with their encodings |
| 03:10.03 | Ori_B | for disassembling? |
| 03:10.10 | danderson | for an emulator/simulator, you need a decoder/dispatcher |
| 03:10.17 | Ori_B | oh, ok. |
| 03:10.20 | Ori_B | yeah. |
| 03:10.31 | danderson | that can identify instructions, deconstruct them, and execute the corresponding functionality |
| 03:11.01 | danderson | the decoders I've seen usually do some comparison of masked bits in the opcode against a jump table |
| 03:11.12 | danderson | but how they get that to work in the general generic case... |
| 03:12.16 | Ori_B | hm. |
| 03:12.26 | Ori_B | I'd have to read the rest of the source... |
| 03:12.33 | Ori_B | and I'm not exactly a lisp guru. |
| 03:12.37 | danderson | Ori_B: if you care, fr30.cpu looks like a fairly simple CPU |
| 03:12.45 | danderson | might be better to get a specific idea |
| 03:12.49 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 03:14.04 | Ori_B | is amused by all the FIXMEs in the ia32 |
| 03:14.14 | danderson | I don't blame them |
| 03:14.18 | danderson | ia32.cpu should be holyshit.cpu |
| 03:14.31 | danderson | at the instruction level, ia32 is quite horrific |
| 03:14.43 | danderson | especially if you want to support horrors like x87 |
| 03:14.55 | Ori_B | danderson: I've considered making my compiler generate x86 binaries directly. I know. |
| 03:15.14 | danderson | seriously, write a gcc frontend |
| 03:15.14 | Ori_B | I punted for now and I'm letting it generate assembly source :) |
| 03:15.22 | danderson | or asm. |
| 03:15.29 | danderson | or an llvm frontend |
| 03:15.30 | Ori_B | GCC frontend isn't half as fun :P |
| 03:15.42 | danderson | generate .ll asm |
| 03:15.45 | Ori_B | danderson: the way I've got it set up, porting the asm generation won't be hard |
| 03:15.54 | danderson | then you can plug in all the optimizer stages llvm has |
| 03:16.07 | Ori_B | it's around 100 lines of code to select instructions |
| 03:16.21 | Ori_B | (and another few hundred to generate the matcher...) |
| 03:16.54 | danderson | well damn |
| 03:17.03 | danderson | their language even knows about sign-extension |
| 03:17.23 | Ori_B | danderson: it knows about pipelining |
| 03:17.28 | danderson | for the fr30 they specify a field "4 bits wide, starting at bit 8, and it's a sign-extended integer" |
| 03:17.36 | danderson | Ori_B: yeah, that's a whole other level of insanity |
| 03:17.40 | danderson | I'm not even going there |
| 03:18.06 | danderson | but a bloody brilliant language for generating a simulator. That much is obvious. |
| 03:18.14 | Ori_B | indeed. |
| 03:18.35 | Ori_B | but look at fr30, near line 43 or so |
| 03:18.42 | Ori_B | that's what convinced me that it's insanely detailed. |
| 03:19.26 | Ori_B | or where they say that they could be specifying how the instruction fetching/decoding works but they're leaving it out |
| 03:19.32 | danderson | yeah, with the description of the pipelines and execution units |
| 03:19.55 | Ori_B | yep. |
| 03:20.05 | danderson | the bit that's getting me is l154 |
| 03:20.19 | danderson | "Here's a 20 bit field that's actually two subfields, and here's how to access it." |
| 03:20.40 | Ori_B | yeah |
| 03:21.19 | Ori_B | wait, 154? |
| 03:21.21 | Ori_B | (dnf f-reg-list "Register list" () 15 16) |
| 03:21.24 | Ori_B | ^- that? |
| 03:21.28 | danderson | um, no |
| 03:21.40 | danderson | (dnmf f-i20 "20 bit unsigned" () UINT |
| 03:21.42 | danderson | that |
| 03:21.54 | Ori_B | oh, looking at the wrong file. |
| 03:21.56 | Ori_B | ignore that. |
| 03:22.03 | danderson | working from the 1.0 tarball, not cvs |
| 03:22.08 | danderson | since the checkout is messed up |
| 03:22.30 | Ori_B | mm, checkout worked for me, it's just really oddly arranged. |
| 03:22.44 | danderson | almost all cpus are missing for me |
| 03:22.48 | Ori_B | /src/cgen/cpu$ |
| 03:22.50 | danderson | not to mention the actual code for the project |
| 03:22.51 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 03:22.57 | Ori_B | ^-- is that where you're looking? |
| 03:23.02 | danderson | yes. |
| 03:23.41 | Ori_B | ok, because I have 'src/cpu' which has a few CPUs |
| 03:24.15 | Ori_B | and src/cgen/cpu which seems up to date |
| 03:24.22 | danderson | yeah, same |
| 03:24.29 | danderson | anyway, I don't mind, 1.0 is fine for now :) |
| 03:24.49 | Ori_B | mhm. |
| 03:25.55 | *** join/#gsoc Ivanovic_ (n=ivanovic@dtmd-4db2a0c2.pool.einsundeins.de) |
| 03:26.08 | danderson | bloody hell |
| 03:26.15 | danderson | the instruction definitions are beautiful |
| 03:26.35 | danderson | "Here's a generic binary integer instruction which updates status flags" |
| 03:27.07 | danderson | "ok, now, here's how you add stuff." |
| 03:30.10 | danderson | mkay, time for sleep |
| 03:30.29 | danderson | tomorrow I need to figure out how they handle stuff like effective address modes |
| 03:30.49 | danderson | the 68k has 12 effective addressing modes, defined in the 6 LSBs of instructions |
| 03:30.57 | Ori_B | cool |
| 03:31.07 | danderson | each one has different implications for where the operands come from and where they go |
| 03:31.18 | danderson | and how they affect address registers and other madness |
| 03:31.34 | danderson | anyway, night. |
| 03:31.40 | Ori_B | hm, how did they actually define the opcodes? |
| 03:33.00 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 04:02.45 | *** join/#gsoc RT|Chatzilla_ (n=rt@reactos/tester/RT) |
| 04:05.28 | *** join/#gsoc mithro (n=tim@unaffiliated/mithro) |
| 04:05.28 | *** mode/#gsoc [+o mithro] by ChanServ |
| 04:52.33 | *** join/#gsoc DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 05:12.45 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 05:22.02 | *** join/#gsoc alunduil (n=alunduil@66.35.127.148) |
| 05:22.37 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 05:25.19 | *** join/#gsoc n|ns3| (n=Jason@cpe-66-75-223-193.bak.res.rr.com) |
| 05:28.18 | *** join/#gsoc takuya (n=Takuya_M@KHP059134240118.ppp-bb.dion.ne.jp) |
| 05:44.27 | *** join/#gsoc alunduil (n=alunduil@199.17.112.1) |
| 06:07.26 | *** join/#gsoc lresende (n=luckbr19@c-67-169-36-7.hsd1.ca.comcast.net) |
| 06:07.53 | *** join/#gsoc sid0 (n=sid0@unaffiliated/sid0) |
| 06:10.20 | *** join/#gsoc yell0w (n=yell0w@cpe-76-183-157-184.tx.res.rr.com) |
| 06:12.17 | *** join/#gsoc sebr (n=seb@amarok/developer/sebr) |
| 06:15.17 | *** join/#gsoc alunduil (n=alunduil@66.35.127.148) |
| 06:23.55 | *** join/#gsoc lresende (n=luckbr19@c-67-169-36-7.hsd1.ca.comcast.net) |
| 06:38.30 | *** join/#gsoc alunduil (n=alunduil@66.35.127.148) |
| 06:58.05 | *** join/#gsoc vonami (n=vonami@83.149.228.131) |
| 07:32.49 | *** join/#gsoc DTRemenak|RDP (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 07:49.21 | *** join/#gsoc mordante (n=chatzill@roadie.xs4all.nl) |
| 08:01.04 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 08:02.43 | *** join/#gsoc RT|Chatzilla_ (n=rt@reactos/tester/RT) |
| 08:02.47 | *** join/#gsoc DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 08:04.42 | *** join/#gsoc vmassol (n=vmassol@49.209.20.81.dynamic.adsl.abo.nordnet.fr) |
| 08:12.48 | *** join/#gsoc Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 08:32.47 | *** join/#gsoc DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 08:55.32 | *** mode/#gsoc [+o kblin] by ChanServ |
| 09:24.48 | *** join/#gsoc vimzard (n=arunc@121.247.219.55) |
| 09:50.38 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 09:52.41 | *** join/#gsoc ice-man (n=iceman@42.Red-83-45-117.dynamicIP.rima-tde.net) |
| 10:00.03 | *** join/#gsoc neptunek (n=neptune@59.92.150.166) |
| 10:02.46 | *** join/#gsoc mirsal (n=mirsal@videolan/developer/Mirsal) |
| 10:07.53 | *** part/#gsoc neptunek (n=neptune@59.92.150.166) |
| 10:14.14 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 10:14.52 | *** join/#gsoc spectie (n=fran@unaffiliated/spectie) |
| 10:25.18 | *** join/#gsoc spectre (n=fran@c5850-a3-2-62-147-21-198.dial.proxad.net) |
| 11:01.24 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 11:09.26 | *** join/#gsoc pygi (n=Mario@241-188.dsl.iskon.hr) |
| 11:10.24 | *** join/#gsoc araujo (n=araujo@190.37.166.81) |
| 11:12.06 | *** join/#gsoc araujo (n=araujo@gentoo/developer/araujo) |
| 11:13.11 | *** join/#gsoc sebr (n=seb@amarok/developer/sebr) |
| 11:33.37 | *** join/#gsoc alanhaggai (n=alanhagg@p3m/member/alanhaggai) |
| 11:34.57 | *** join/#gsoc bentob0x (n=laurent@ip-213-49-64-162.dsl.scarlet.be) |
| 11:55.19 | *** join/#gsoc thiago (i=thiago@kde/thiago) |
| 11:56.14 | *** join/#gsoc jaguarandi (n=darkaj@85.138.59.241) |
| 12:02.51 | *** join/#gsoc k0p (n=luis@bl8-170-238.dsl.telepac.pt) |
| 12:23.38 | *** join/#gsoc jkerihuel_ (n=jkerihue@ASt-Lambert-152-1-24-113.w82-120.abo.wanadoo.fr) |
| 12:33.53 | *** part/#gsoc n|ns3| (n=Jason@cpe-66-75-223-193.bak.res.rr.com) |
| 12:48.51 | *** join/#gsoc alanhaggai_ (n=alanhagg@p3m/member/alanhaggai) |
| 13:01.20 | *** join/#gsoc dirigeant (n=dirigean@unaffiliated/mew/x-344925) |
| 13:03.31 | *** join/#gsoc i386 (n=james@ppp201-143.static.internode.on.net) |
| 13:06.22 | *** join/#gsoc i386 (n=james@ppp201-143.static.internode.on.net) |
| 13:13.38 | *** join/#gsoc sanjiv (n=chatzill@59.180.187.97) |
| 13:16.18 | *** join/#gsoc araujo (n=araujo@gentoo/developer/araujo) |
| 13:25.53 | *** join/#gsoc ondrej (n=ondra@ip4-83-240-41-73.cust.nbox.cz) |
| 13:44.15 | *** join/#gsoc pygi (n=Mario@241-188.dsl.iskon.hr) |
| 13:56.22 | *** join/#gsoc spectie (n=fran@unaffiliated/spectie) |
| 14:21.03 | *** join/#gsoc nithinkumary21 (n=nithin@203.78.217.160) |
| 14:37.20 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 15:01.40 | *** join/#gsoc vimzard (n=arunc@121.247.248.231) |
| 15:05.12 | *** join/#gsoc sanjiv_ (n=chatzill@59.180.143.46) |
| 15:06.59 | *** join/#gsoc pygi (n=Mario@241-188.dsl.iskon.hr) |
| 15:11.25 | *** join/#gsoc spectie (n=fran@unaffiliated/spectie) |
| 15:16.10 | *** join/#gsoc dirigeant (n=dirigean@unaffiliated/mew/x-344925) |
| 15:45.16 | *** join/#gsoc k0p (n=luis@bl8-170-238.dsl.telepac.pt) |
| 16:17.52 | *** join/#gsoc vimzard (n=arunc@121.247.248.231) |
| 16:22.02 | *** join/#gsoc JeffM (n=JeffM@65-73-179-21.bras01.sho.az.frontiernet.net) |
| 16:26.59 | *** join/#gsoc ptomaine (n=ptomaine@enlightenment/developer/ptomaine) |
| 16:29.05 | danderson | hrm |
| 16:29.21 | danderson | cgen's RTL is nice, but it seems to fail to be what I need |
| 16:29.34 | danderson | I'd have to define by hand the 56 variants of the ADD opcode |
| 16:29.43 | danderson | because they have different addressing modes |
| 16:30.48 | danderson | which appears to be why the m68k .cpu only has 10 instructions |
| 16:30.57 | danderson | and only the simple ones with no operands, or a single operand form |
| 16:34.42 | danderson | and it's frustrating, the description language is almost what I need |
| 16:34.45 | danderson | ... but not quite :( |
| 16:46.46 | *** join/#gsoc dirigeant (n=dirigean@unaffiliated/mew/x-344925) |
| 16:55.44 | *** join/#gsoc nithinkumary21 (n=nithin@59.162.23.221) |
| 17:09.35 | *** join/#gsoc jabagawee (n=jabagawe@unaffiliated/jabagawee) |
| 17:34.59 | *** join/#gsoc khetzal (n=quetzal@2a01:e35:8b51:6f0:216:d4ff:fe2d:ffbe) |
| 17:42.22 | *** join/#gsoc Davbo (n=dave@78-86-138-216.zone2.bethere.co.uk) |
| 18:00.42 | *** join/#gsoc mirsal_ (n=mirsal@ALyon-258-1-110-202.w90-53.abo.wanadoo.fr) |
| 18:11.17 | *** join/#gsoc vimzard (n=arunc@121.247.248.231) |
| 18:13.19 | *** join/#gsoc spectie (n=fran@unaffiliated/spectie) |
| 18:23.41 | *** join/#gsoc vmassol_ (n=vmassol@49.209.20.81.dynamic.adsl.abo.nordnet.fr) |
| 18:31.03 | *** join/#gsoc lusterlink (i=4819516e@gateway/web/ajax/mibbit.com/x-c71effcadccdbf3a) |
| 18:33.07 | *** join/#gsoc lresende (n=luckbr19@c-67-169-36-7.hsd1.ca.comcast.net) |
| 18:56.58 | *** join/#gsoc JeffM (n=JeffM@65-73-179-21.bras01.sho.az.frontiernet.net) |
| 19:18.24 | *** join/#gsoc jabagawee (n=jabagawe@unaffiliated/jabagawee) |
| 19:24.11 | *** part/#gsoc k0p (n=luis@bl8-170-238.dsl.telepac.pt) |
| 19:24.46 | *** join/#gsoc nithinkumary211 (n=nithin@203.78.217.160) |
| 19:32.13 | *** join/#gsoc [mharrison] (n=mharriso@c-71-192-116-155.hsd1.ma.comcast.net) |
| 20:03.25 | *** join/#gsoc ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) |
| 20:27.50 | *** join/#gsoc lresende (n=luckbr19@c-67-169-36-7.hsd1.ca.comcast.net) |
| 20:54.41 | *** join/#gsoc sid0 (n=sid0@unaffiliated/sid0) |
| 21:14.06 | *** join/#gsoc stefanb85 (n=stefan@86.121.81.191) |
| 21:17.48 | *** join/#gsoc Rob0tnick (n=arunc@121.247.248.231) |
| 21:23.22 | *** join/#gsoc lyaunzbe (n=lyaunzbe@142.131.89.82) |
| 21:25.54 | *** join/#gsoc pygi (n=Mario@241-188.dsl.iskon.hr) |
| 21:26.22 | *** join/#gsoc spearce (n=spearce@72.14.224.1) |
| 21:31.29 | *** join/#gsoc nithinkumary21 (n=nithin@59.162.23.221) |
| 21:38.48 | *** join/#gsoc vimzard (n=arunc@121.247.248.231) |
| 21:57.01 | *** join/#gsoc thiagoss (n=thiagoss@189.71.76.112) |
| 22:06.35 | *** join/#gsoc samer (n=sziadeh@CPE001ff355f765-CM001ac35cd4b4.cpe.net.cable.rogers.com) |
| 22:36.35 | *** join/#gsoc Davbo (n=dave@78-86-138-216.zone2.bethere.co.uk) |
| 22:57.23 | *** part/#gsoc mlankhorst (n=m@fw1.astro.rug.nl) |
| 23:24.35 | *** join/#gsoc spearce (n=spearce@c-24-6-210-175.hsd1.ca.comcast.net) |
| 23:27.19 | *** join/#gsoc spearce` (n=spearce@72.14.224.1) |