00:02:21 -!- Sgeo has joined. 00:07:41 -!- TeruFSX has joined. 00:14:52 -!- jiella has quit (Quit: Leaving.). 00:18:07 -!- kwertii has joined. 00:18:21 > (zipWith (/) `on` map (fromIntegral . ord)) "A[bbe\GSPehbZ\RS" "Hello World!" -- previous 10% bug, fwiw 00:18:23 [0.9027777777777778,0.900990099009901,0.9074074074074074,0.9074074074074074... 00:45:07 olsner: what was this esolang again, i vaguely recall this 10% bug thing... 01:10:22 -!- monqy has quit (Quit: hello). 01:44:07 -!- trout has changed nick to const. 01:50:52 -!- madbr has joined. 01:52:50 -!- oerjan has quit (Quit: Ribbit). 01:55:52 -!- Jafet has quit (Quit: Leaving.). 02:19:40 -!- TeruFSX has quit (Ping timeout: 246 seconds). 02:33:20 -!- olsner has quit (Ping timeout: 246 seconds). 02:33:48 -!- olsner has joined. 02:37:52 http://goatkcd.com/1115/sfw [nsfw] 03:06:35 -!- Jafet has joined. 03:14:55 -!- ogrom has joined. 03:16:14 -!- ogrom has quit (Client Quit). 03:38:22 What does 6502 do on each cycle of an instruction? 03:39:09 usually a memory operation 03:39:50 in some cases just an "internal operation" (all 2 cycle instructions that don't access memory are like this) 03:40:08 such as nop (2 cycles) 03:40:33 or lsr a (2 cycles) 03:40:55 But in instructions taking longer to execute, what memory access read/write done with each cycle? When does it read the next instruction and its operands? 03:41:09 (a large majority of cycles do a memory op) 03:41:24 hm 03:41:36 I don't think it is pipelined 03:42:14 so a cycle is something like 03:42:46 [cycle 1] read instruction 03:43:17 [cycle 2] no memory op but ALU is active 03:44:01 If there is no memory operations, what is on the address bus at that time? 03:44:09 who knows 03:44:44 -!- sivoais has quit (Ping timeout: 246 seconds). 03:44:46 F L O A T I N G B U S 03:44:46 probably the same address as last cycle, or 0 03:44:57 or z :D 03:46:10 fun fact: the original nmos 6502 was so slow that it actually only accessed memory half the cycles on the Apple II 03:46:24 the other half was used by the video display :D 03:46:50 i heard the original nmos 6502 would also do crazy shit if you gave it invalid instructions 03:46:52 Now I know. 03:47:23 kmc: yeah that's what the docs say :D 03:47:24 I think there are unofficial instructions? 03:47:38 i thought some of them were byproducts of the instruction decode logic 03:47:47 zzo: the docs say that a lot are unstable 03:47:58 plus they won't work on a 65816 03:48:06 Yes I know, I read that some are unstable, but they said some are stable. 03:48:38 But some are the same as other instructions and so are not so useful unless you are also using the instruction opcodes as data in the same program 03:48:44 -!- sivoais has joined. 03:49:18 Demo sceners have been using the “invalid” 6502 instructions a lot. 03:49:54 supposedly they do weird shit like adding and anding stuff at the same time 03:50:13 Such things can occasionally be useful. 03:50:46 If you’re counting cycles, certainly. 03:51:31 I have added the stable unofficial instructions into Unofficial MagicKit (only available for targets which do not override those instructions with new ones) 03:53:04 reading about the 6502 it does come off as totally underpowered 03:53:28 or even the 65816 04:01:25 6502 has decimal mode, but some 6502 based computers lack decimal mode 04:03:03 who uses decimal mode? 04:03:13 Is the decimal mode useful for something other than decimal calculation? 04:03:39 trolling 04:03:42 I don't know who uses decimal mode. 04:03:52 my guess is: banks 04:05:59 Some programs I wrote are for Famicom which lacks decimal mode, so I have never used it. If I program a computer which does have decimal mode I may sometimes used it. 04:06:25 x86 has some instructions for BCD arithmetic. 04:06:41 But I think they cannot be used in 64-bit mode. 04:07:04 correct :/ 04:07:34 they are useful for things besides BCD 04:07:47 AAM does AH <- AL / 10; AL <- AL % 10 04:07:56 but you can actually change that 10 by changing the second byte of the instruction 04:07:58 Yes, AAM and AAD, you can change the base 04:08:01 I know that 04:09:47 So I suppose setting the base to 1 would be a way to move AL to AH and then set AL to zero, it might be slower but it might also be a smaller code 04:09:58 What happen if you set the base to zero? 04:11:00 Will GCC or LLVM make these instructions if it is not 64-bit mode? 04:12:12 probably not imho 04:12:24 they probably don't run fast on modern processors 04:12:52 I know it may be slow, but might it sometimes result in a smaller code, if you select that option for some subroutines? 04:13:11 smaller code? 04:13:41 like, you can't even express BCD operations in C/C++ afaik 04:13:54 In case you want to optimize some functions for size and some for speed 04:15:29 how would you shrink a function by using BCD? 04:15:34 I know C has no commands for BCD operation, and LLVM also has no commands for BCD operation, but some things may sometime result in equivalent to such operation, or even other operation which the target computer may have 04:17:01 madbr: I don't know, but it might if the function is used for making BCD calculation. And anyways, the AAM and AAD instruction can be used for operations other than BCD arithmetic too. 04:17:23 like what 04:18:05 They described above AAM does AH <- AL / 10; AL <- AL % 10 but it does not have to be 10 you can use a different number instead 04:18:33 -!- kwertii has quit (Quit: kwertii). 04:20:39 Such as if you just want to move AL to AH and then set AL to zero, or to move some of the bits of the numbers in certain way, it would probably be very slow to use division but may result in a smaller code, such as if used only for initialization, or if you want the code to fit in MBR 04:22:57 perhaps 04:23:13 still hare brained and no new instruction set should have those monstruosities :D 04:24:35 like, wtf, 6 BCD instructions on x86 04:24:45 which could have been something useful instead 04:25:55 Yeah, but in CISC design it almost makes sense 04:26:54 Well, I think AAM and AAD are useful instructions. 04:27:06 -!- Jafet has quit (Ping timeout: 245 seconds). 04:27:10 they all have 1 byte opcodes too 04:27:52 zzo: no way 04:28:09 they take 10/18 cycles on the pentium 04:28:23 bear in mind that x86 is evolved from a wee little calculator processor 04:28:51 Yeah. Its lineage goes back to a CPU with 4-bit address space for a desktop calculator. 04:28:53 -!- Jafet has joined. 04:29:06 Erm. Was it 4 bit address space? 04:29:12 depressing but true 04:29:13 Might've just been 4 bit registers. 04:29:19 Anyways. Silly. 04:29:42 12-bit address space. 04:29:46 4 bit registers. 04:29:48 amazingly it's still better than the 6502 04:30:09 which never got a 32bit version 04:30:21 It did. 04:30:36 Sorry, thinko. 04:30:39 It got a 16 bit version. 04:30:41 Yes they are too slow, but if they are not too slow it may sometimes be useful, and it can also be useful if you do not need it to be fast 04:30:50 yeah, 65816, used on the snes 04:31:06 *Not* a 32 bit version. 04:31:33 zzo: you could simply store a LUT somewhere 04:32:07 and do the same operation in 1 cycle, pairable on the pentium 04:34:45 it's all about the pentiums 04:36:18 well, essentially on the pentium they decided which instructions would be fast, and which ones would be slow 04:36:29 and the same selection applies to the later processors 04:37:58 and essentially that's where they turned x86 into a bogo-risc 04:45:17 kmc: mosh works with the scroll wheel now? 04:45:48 it does? 04:45:59 for what values of "works"? 04:46:15 I'm moshing to my irssi and scrolling the scroll wheel goes up and down in history. 04:46:43 huh 04:47:04 i am surprised 04:47:22 Hmm, this might be a fluke. 04:47:31 -!- Jafet has quit (Quit: Leaving.). 04:47:39 i don't think we're setting alternate screen on the client 04:47:42 https://github.com/keithw/mosh/issues/2 is still open 04:47:48 you can ask in #mosh though 04:47:50 Yep, even if I detach from screen, scroll-wheel goes up and down in bash history. 04:48:08 Somehow I got into scroll-wheel-sends-up-and-down-arrows mode, or something. 04:49:10 huh 04:49:12 well that's useful 04:50:18 in the neon sign, scrolling up and down, i am born again 04:50:20 kmc: Hah, irssi put me in this mode. 04:50:25 irssi ate my balls 04:50:31 brb 04:50:39 I previous sshed to irssi and exited with ~. 04:57:57 the ARM has like 10 different multiply instructions 05:00:57 wait no 05:00:58 20 05:00:58 What kind of multiply instrucions? 05:01:10 multiply, multiply accumulate, multiply subtract 05:01:20 multiply to 64 bit 05:01:24 multiply 16 bit 05:02:38 weird "wide" multiply (32*16) 05:03:29 multiply 16 bit into 64 bit accumulator (weird :o ) 05:04:25 double 16 bit multiply adding/subtracting the productions 05:05:06 32 bit mul keeping only the most significant 32 bits of the result 05:06:31 dual 16bit multiply adding/subtracting the products then accumulating 05:07:29 multiply with combining grass radical above 05:07:35 same but accumulating 64bit 05:08:36 multiply 32 bit into 64bit accumulator 05:08:39 and that's it 05:09:00 ...for the non SIMD multiplications :D 05:09:18 the SIMD ones are even crazier :D 05:13:38 good thing ARMs don't have bcd 05:17:15 Do you know any computers with a triple indirect jump with post increment instruction? 05:18:38 well the RCA 1802 has weird indirect registers 05:18:40 "Using the SEP instruction, you can select any of the 16 registers to be the program counter; using the SEX instruction, you can select any of the 16-bit registers to be the index register." 05:19:08 but i don't know what the addressing modes are 05:19:16 zzo38: do you want this address mode for any particular purpose? 05:20:05 I am just wondering if anything has something like that. 05:20:48 It allows you to change which register is the program counter? I have never seen anything like that before. 05:21:05 yes 05:21:23 as wikipedia describes, this was sometimes used for fast subroutine calls, even alternating coroutines 05:30:07 so CISC 05:30:13 sooooooooo CISC 05:32:23 can be translated as "this architecture will never be able to be pipelined" 05:34:59 heh 05:35:27 ARM lets you swap the contents of the instruction pointer and another register, right? 05:35:31 that is similarly useful and less crazy 05:35:56 yeah ARM has the PC as one of the GPRs 05:36:05 which turned out to be a mistake 05:36:21 now if you look at the ARM manual most instructions say 05:36:44 "non of the operands of this instruction can be r15 (pc)" 05:37:02 that's too bad 05:37:27 it's ok when you're running at 10mhz and your pipeline is 2 cycles long 05:38:24 once your cpu is doing 2 instructions at the same time then your PC is not your PC anymore 05:38:58 not to mention crazy out of order CPUs (essentially all modern CPUs) 05:39:47 -!- sivoais has quit (Read error: Connection reset by peer). 05:40:04 CISC? 05:40:06 Pipelined? 05:40:25 sgeo: it's possible! 05:40:34 -!- sivoais has joined. 05:40:39 As in, I don't know what either of those mean. 05:41:00 I know RISC is reduced ... something about few instructions 05:41:08 Like a small number of opcodes or something 05:41:20 yeah 05:41:52 a CPU has several stages to process an instruction 05:42:13 fetch the instruction from memory, figure out what it means, fetch operand(s) from memory, do arithmetic or whatever, save result 05:42:18 risc = lots of registers, high instruction set orthogonality 05:42:28 each of these has a different piece of hardware 05:42:42 it would suck if we only used one of those units at a time 05:42:50 yeah but the number of stages varies a lot 05:42:59 in a pipelined processor we are fetching one instruction while we decode the previous one, while we fetch for another, etc. 05:43:04 yeah this is a simplistic explanation 05:43:06 but that's the idea 05:43:23 Ah 05:43:52 the ideal early RISC cpu runs 1 instruction per cycle 05:43:54 another way to look at it is, if you tried to do all that stuff in one clock cycle, your max clock speed would be really low, because of the delay to propogate through all those logic gates 05:43:56 What happens with jumps or conditionals? 05:44:10 sgeo: depends on the length of the pipeline 05:44:13 yeah, that's a trick 05:44:28 this is why on MIPS processors, the instruction after a branch gets executed even if the branch is taken 05:44:35 on longer pipelines and stuff like the x86 it tries to predict the result 05:44:46 RISC processors tend to expose these implementation details, on the grounds that the compiler can deal with them 05:45:10 Oh, hmm. I thought maybe the fetched thing that was after the jump just gets discarded 05:45:26 sgeo: not on the MIPS 05:45:35 yeah you can stall the pipeline like that 05:45:43 it makes CPUs easier to design 05:45:54 but then you're executing fewer than one instruction per clock 05:46:05 if the compiler has nothing useful to put there, it can insert a NOP 05:46:08 but there's not much point later on when your pipeline is 8 cycles and you have to do branch prediction anyways 05:46:09 otherwise maybe it can do some useful work 05:46:33 1 cycle isn't much, you can pretty much always put something there 05:47:20 Sgeo: another problem is data dependencies, what if a write and a read from the same register are in the ppipeline at the same time 05:47:31 oh yeah 05:47:48 you can stall, or you can insert "bypass" paths which let it read the value that will be written, rather than the stale value that's in the register file 05:47:54 which adds complexity 05:48:00 MIT's 6.004 is a really nice intro to this stuff 05:48:03 if your cpu is a well designed RISC you can do these all in 1 cycle 05:48:13 you design a RISC processor in a logic gate level simulator 05:48:19 and then you can optimize it for speed 05:48:32 the labs and software are available online 05:48:33 but once you're doing like 2 operations at the same time etc you have to introduce stalls 05:48:41 or out of order execution 05:49:09 i did the 2 stage pipeline with stalls on branches, which wasn't too bad 05:49:16 but more than 2 stages gets hairy 05:50:32 TMS320C64x has two-instruction delay slots. Except it's one instruction if it's one of the instructions that are followed by an immediate word. Keeping track of that kind of thing manually is kind of a pain. (Though I suppose you're meant to mostly just write C and use the provided algo libs.) 05:50:45 that's a DSP? 05:50:52 Yes. 05:51:00 VLIW is still popular for DSPs right? 05:51:02 * kmc does not know why 05:51:19 kmc: they're probably easier to design 05:51:49 of course that's a road to the intel itanium and we all know what happened to that one :D 05:51:54 I don't know how popular; the C64x used by the popular-in-phones OMAP platform (at least OMAP3 and I think 4 too) is a VLIW thing. 05:52:03 it's amazing how far the inner workings of a CPU are from the virtual machine suggested by the instruction set 05:52:16 when people talk about how C and assembly tell you "what the machine is really doing" i just laugh and laugh 05:52:39 They tell you what *a* machine is really doing. 05:52:44 (of course with C people also forget that there's an optimizing compiler which can make liberal use of undefined behavior) 05:52:47 There's always another turtle somewhere. 05:52:52 yeah 05:53:02 but they act like they've found the bottom turtle and it's special 05:53:33 anyway 05:53:37 We should make up the CPU where the instruction set corresponds closely to the inner working and work faster too. 05:53:38 The ISA is a pretty good turtle. 05:53:44 well, it's the bottom turtle you can actually write for 05:53:52 zzo38: that is the idea of RISC basically 05:53:54 zzo: that's called a VLIW 05:54:19 yeah i guess VLIW is that idea for superscalar 05:54:25 zzo: the big problem with VLIW is that they bust the instruction cache 05:54:42 you'd end up with an instruction word like 05:54:49 kmc: Doncha *love* it when people act like x86 asm is what the machine "really does"? 05:54:58 shachaf: do you know about implementing a touch / proximity sensor with two digital I/O pins, a resistor, and a piece of wire? 05:55:13 kmc: Nope! 05:55:18 Rather than just being the lowest abstraction Intel provides? *urgh* 05:55:22 -!- nortti has quit (Ping timeout: 268 seconds). 05:55:25 well you set one pin as input and one as output 05:55:41 connect the pins with a big resistor (≥ 1 MΩ) 05:55:48 add r0, r1, r4 sub r3, r7, r8 add r9, r2, r14 shfnop mulnop ldr r5, r13 05:55:50 I have had ideas of CPU instruction sets based on what is hardware what I was thinking of. 05:56:01 and also connect your wire or metal plate to the input pin 05:56:18 essentially a bunch of ALUs, each one gets an operation on every cycle 05:56:28 then you simply toggle the voltage at the output, and see how long it takes the input to match 05:56:43 this is a measure of the capacitance on that pin, which will change if someone touches or gets near the wire / plate 05:56:54 the other big problem with an architecture like that is that, what happens if you have a cache miss? 05:57:12 Makes sense. 05:57:16 you'd have to stall everything 05:58:05 also you'd probably have to cover the chip in multiplexers 05:58:55 the other other problem is that your compiler has to be crazy smart 05:59:05 true 05:59:08 Another idea I have, is first you need a open-specification FPGA (some people have partially reverse-engineered the AT40k FPGA, so we can use that), and have a compiler which takes LLVM codes with speed annotations (such as: this function runs in less than 1 million clock cycles if the third parameter is divisible by 5) and creates a hardware optimized for running this program. 05:59:13 dunno how smart it would have to be but yeah 05:59:48 would be workable if it could reorder operations over multiple loop iterations but afaik C pointers usually have some ways to defeat that 06:00:10 Does what I said would work at all? 06:00:35 tho I've heard that GCC is even able to autovectorize loops so it might be workable after all 06:01:20 If the FPGA is capable of reprogramming itself at runtime, then you can have not only self-modifying software codes, but you can have self-modifying hardware codes as well. 06:01:34 perhaps VLIW is popular for DSP because people are willing to hand-code these algorithms (and use them from libraries) rather than expecting to feed some 40 year old FORTRAN codes in and get good performance 06:01:54 imho the problem is C/C++ 06:02:10 kmc would surely agree that "C/C++" is a problem. 06:02:31 using "code" as a non-uncountable noun is a sign that one has worked in academic computing 06:02:36 What problem is C/C++? It has some problems but I don't know what problem you mean. 06:02:38 like "here is a code for fourier transform" 06:02:48 "here is a collection of codes for manipulating splines" 06:03:21 zzo: the general problem is that the user might throw weird pointers at your algo 06:03:26 I thought "code" as a non-uncountable noun is a sign that you don't understand programming at all and want people to give you stuff to copy and paste 06:03:29 -!- nortti has joined. 06:03:33 like multiple buffers that are really the same buffer 06:04:32 It is why you have to specify in your documentation, if it is allow to be the same buffer or not, and stuff like that 06:04:47 the compiler doesn't know that 06:04:59 well you can use the 'restrict' keyword in some cases 06:05:01 zzo: that's why older C/C++ compilers have a "no aliasing" switch 06:05:10 I think they added the "restrict" keyword so that the compiler will know that? 06:05:21 which means that you promise pretty promise that you're not going to do it 06:05:22 And I also think LLVM has corrected some things? 06:05:34 Does LLVM have all of these things better way? 06:05:42 though recent compilers don't seem to have the switch so they might have found out some better way yeah 06:07:04 if that is the case it reduces the VLIW's problems to "code size" and "how to prevent a stall when you have to fetch the data all the way from the RAM" 06:07:48 stopping irssi with ^z accidentaly seems to result in nothing else than disconnection from everywhere 06:08:27 My stomach hurts, don't know if it's hunger or nausea 06:08:32 Or what 06:09:24 My idea is to have multiple memory connected, one for program, one for data X, one for data Y, and any of them can be switched with each other, and then have the address bus for data X and Y to be their own registers, the data bus are also their own registers, use LFSR-based PC with one register affecting the LFSR taps, an instruction transfer register to register with condition.... 06:09:43 zzo: you don't need multiple memories when you have cache 06:10:52 Having the LFSR-based PC with a register affecting the LFSR taps is somewhat like having a multi-dimensional programming language, if done in the correct way needed to do this, I guess 06:11:18 O, and then also add multiplexer calculation like how the Muxcomp esolang does it 06:11:51 These are just some ideas I have to make a CPU; I don't know how it is really working. 06:12:31 I'd try going for one that has the maximum number of ALUs 06:12:35 madbr: But when you have cache, don't you then also need to have stuff such as cache invalidation and checking if it is cache and so on, unless your instruction set is dealing directly with the cache 06:12:48 and base everything else around keeping those ALUs full most of the time 06:13:41 zzo: yeah but afaik that's not so bad 06:14:57 It also seems difficult to predict how many clock cycles a certain sequence of instructions will take if it automatically reorders them and put into cache and all that other stuff. 06:16:45 true but still 06:16:58 considering how DRAM works it's a lot faster to have cache 06:17:30 also it prevents the need of having multiple ram areas for program, data x etc... 06:17:47 OK, but I still want it that the cache only works with instructions that directly tells the cache what to do 06:18:33 yeah but then the compiler has to guess what goes in cache 06:18:53 and all the manual cache management will probably slow it down a lot 06:20:24 the big benefit of cache is that essentially your inner CPU core doesn't have to deal with DRAM anymore 06:20:49 it becomes just "load from cache, stall if I get a cache miss" 06:21:31 right, for a long time the DRAM controller wasn't even on the processor 06:22:30 But you could require that instructions can only execute from cache, and these instructions modify other instructions in cache in order to affect the values you are dealing with, and have the external address/data bus to just be registers visible to the program stored in cache 06:23:46 good luck writing a program for that 06:25:24 You could then also have multi-cores executing separate programs simultaneously, with some registers shared, and others which are not shared, and some which are partially shared. 06:26:01 aka the Cell processor 06:30:56 Or have something like that checkboard design mentioned on esolang list of ideas, which has the checkerboard of processor and memory (so each processor accesses four memory cores and each memory is accessed by four processor cores) 06:31:17 I don't know how well it would work 06:31:22 hm 06:31:43 I'm not familiar with multicore operation 06:31:55 Neither am I, actually. 06:32:19 except from the user point of view ("you have to mutex everything because nothing happens in the real order") 06:33:06 I wrote in esolang list of ideas, make a programming language which requires bus conflicts and race conditions in order to work. 06:33:29 one nice idea I had is a dataflow processor 06:33:44 like, instead of having "write x to register y" 06:33:57 have each register take a new value each cycle 06:34:06 and have one ALU per register 06:34:17 Yes, do like that. 06:34:25 Somehow. 06:35:29 maybe with access to values produced 2 or 3 cycles ago 06:35:38 OK 06:35:39 or switching between two sets of registers 06:36:25 What would you think about my idea of making the program which includes the hardware description of the CPU optimized to execute this specific program? 06:36:42 afaik that already exists 06:37:06 Is it possible to compile LLVM programs into such things? 06:39:25 no, it's some crazy expensive design software 06:40:12 afaik most people just get a fast ARM system on a chip and run the C++ on that instead :D 06:41:58 it's probably not very different from writing a C++ program and optimising the few loops that run a lot in ASM 06:44:11 http://jollatides.com/2012/10/01/jolla-handset-poll-give-jolla-your-feedback/ 06:48:12 the other weird thing is that the amount of gates and latency of components like adders can vary 06:49:23 afaik modern processors use very low latency adders which means they're probably enormous 06:49:48 ARM has some complicated instructions, requires memory of differing data sizes, apparently you are not allowed to use some instructions unless you pay them, and OpenCores made a "Amber" processor based on ARM but they were sued and not allowed to make anything beyond ARMv2 06:50:43 heh 06:50:51 Oooh: a CPU where you have to plug in a credit card to enable some parts of the instruction set. And a per-instruction charge. Careful with those loops, now! 06:51:20 I think this is stupid so I do not want to use ARM in a computer design. 06:51:23 fizzie: that's ARM's revenue model 06:52:13 from what I can tell they license the SIMD unit and stuff like that 06:52:52 which is why some androids don't have them and you have to have a C++ version of like everything :D 06:53:40 Perhaps, but it doesn't quite go as far as getting money when the individual end users want to run something that takes advantage of tricky parts. 06:53:46 multiple data sizes is ok, the really complicated one afaik is when you allow unaligned accesses 06:54:34 supposedly there's a patent on that too 06:58:57 how about a design that has 2 modes: RISC, and VLIW 06:59:16 RISC is designed to run C++, have compact code (16bit opcodes) 06:59:40 VLIW is for the few inner loops that run a lot and have to be optimised 07:01:03 the vliw mode can probably even be specially simplified 07:01:47 since it probably doesn't have to deal with, say, real branching 07:02:05 it's going to mostly loop the same piece of code hundreads of time 07:02:16 ok sleep 07:02:18 -!- madbr has quit (Quit: Radiateur). 07:04:04 Blerp. They upgraded this workstation, and now XMonad keybindings for switching between monitors (mod-{w,e,r}) are in the wrong order, because screen 0 happens to be the right one, not the left one. 07:07:08 Man, these Intel model numbers, I've completely lost track of them. It used to be so simple. 07:07:20 Now this new workstation has an "E31230". 07:22:46 What hardware programming language would you program it by specifying what gates you use and what connection you use between them and what propagation delay? 07:31:09 -!- zzo38 has quit (Remote host closed the connection). 07:46:23 I wonder if he was trying to describe something like verilog 08:03:54 -!- atriq has joined. 08:04:04 @messages? 08:04:04 Sorry, no messages today. 08:10:22 I can't rotate this single screen when it's in a NVidia TwinView configuration? 08:15:40 fizzie, my lack of knowledge of C is letting me down 08:15:53 Does "typedef int8_t jbyte" name jbyte as a type synonym of int8_t? 08:16:08 Yes. 08:16:14 Okay 08:16:27 So, in Haskell, that'd be something like "type JByte = Int8" 08:17:33 If you take a regular declaration that makes 'foo', say, a pointer to a no-arg function returning int -- int (*foo)(void) -- then adding a typedef in front makes 'foo' a synonym for the type it would've normally made 'foo' an instance of. 08:18:17 Okay 08:18:28 "In a declaration whose storage-class specifier is typedef, each declarator defines an identifier to be a typedef name that denotes the type specified for the identifier in the way described in 6.7.6." 08:18:44 It's kind of a silly that 'typedef' is a "storage-class specifier". 08:19:37 ("The typedef specifier is called a ‘‘storage-class specifier’’ for syntactic convenience only.") 08:19:43 -!- Arc_Koen has joined. 08:23:02 Well, my C textbook is new enough to tell me about typedef, and despite elliott's recommendations I have not burnt it yet. 08:23:05 So, I'll read that 09:05:34 -!- pikhq_ has joined. 09:05:44 -!- pikhq has quit (Ping timeout: 255 seconds). 09:06:56 hello 09:07:02 Hey 09:07:32 so what's up? have you completed your fueue interpreter in haskell? 09:07:45 > (replicate 3 ) (replicate 2 [2, 2]) 09:07:47 [[[2,2],[2,2]],[[2,2],[2,2]],[[2,2],[2,2]]] 09:07:52 Haven't been working on it 09:08:04 I'm trying to port something fizzie and elliott made a while back to Haskell 09:13:48 I'm having difficulties in that C is not Haskell 09:17:56 atriq: go on 09:18:06 * kallisti has been working on a term rewriting grammar 09:18:10 Mutable variables, for a start 09:18:43 Actually, that's the only difference between C and Haskell I'm having trouble accounting ofr 09:18:45 *for 09:18:53 pattern -> [replcaement | condition] 09:19:01 each symbol has a weight 09:19:03 so it's really a tuple 09:19:31 Is there a way to search a github thing? 09:19:43 .. 09:19:50 uh, github? 09:19:55 No 09:20:02 A thing on github 09:20:06 * kallisti sips gumbo 09:23:02 atriq: GitHub's own "advanced search" form at least at some point. 09:23:09 Okay 09:23:39 You need some kind of a "repo:foo/bar" specifier and then tell it to search from source code too. 09:24:32 https://github.com/search and the bits about "Code Search". 09:28:53 atriq: I actually have a private git server 09:28:58 I could set up a web interface 09:29:05 No, it's okay 09:35:03 arrrrrrh 09:35:12 that was too easy 09:35:25 but I forgot about nested loops 09:35:56 how the hell can a brainfuck interpreter in thue account for nested loop? 09:36:21 -!- mig22 has joined. 09:36:28 in order to "jump to the matching ]" I usually have a variable that count how deep in nested loops the ip is 09:36:35 but thue has no variables 09:37:28 Arc_Koen: I was thinking of a string rewriting grammar that uses a term rewriting system 09:37:33 but on a tree of weighted values 09:37:47 with conditions on the weights, and a pattern from the tree 09:38:17 and the resulting term and also an update of the current state of the weight. 09:39:22