From: C R Onjob Date: Wed, 9 Apr 2014 17:00:02 +0000 (+0800) Subject: Automatic commit of irc logs X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=947eabac92e8b79f39669f703c1acba7ea92714b;p=ipdf%2Fdocuments.git Automatic commit of irc logs When I reflect upon the number of disagreeable people who I know who have gone to a better world, I am moved to lead a different life. -- Mark Twain, "Pudd'nhead Wilson's Calendar" --- diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 91c4f45..258dd65 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -112,3 +112,81 @@ 11:31 <@matches> The "Experiment Running" sign seems to have worked 11:31 <@matches> Also open source VHDL stuff is less "actually compiles" than I had hoped 11:32 <@matches> The two I've tried so far seem to generate absolute monstrosities of C or C++ files and then fail to compile and/or link +--- Day changed Wed Apr 09 2014 +15:27 <@sulix> So I've been hitting my head against my desk for about half an hour trying to work out where some bugs were in some ipdf code I'm writing. +15:27 <@sulix> Turns out to have mostly been precision issues due to the lack of precision in your Real data type. +15:28 <@sulix> Switching it to double fixes them all. +15:32 <@matches> Oh +15:32 <@matches> Sorry +15:37 <@sulix> Nah: it's good. It means that precision actually is important! +15:37 <@sulix> (I was getting a little bit concerned for a while :P) +15:40 <@matches> Well +15:40 <@matches> I have rediscovered just how awful VHDL is +15:41 <@matches> It seems like you can't define anything without typing it three times +15:42 <@matches> You define an entity +15:42 <@matches> Then you define a component with identical ports +15:42 <@matches> Then you tell it to use the entity for that component +15:42 <@matches> Then you tell it to map the identical ports to the entity ports +15:42 <@matches> adder_0 : adder port map (a=>a, b=>b, cin=>cin, s=>s, cout=>cout); +15:44 <@matches> Pretty much all the hardware papers I found talk about using VHDL for things +15:46 <@matches> Let's see if I can make any sense of this jop-devel thing that appears to be a JVM implemented in VHDL +15:47 <@matches> Uh oh, .bat files +15:48 <@matches> This looks ominous +15:51 <@sulix> The whole swapping out main thing breaks the makefile in a few ways btw. +15:51 <@sulix> Because none of main.cpp's dependencies are listed. +15:51 <@matches> Ah +15:51 <@sulix> So if you change main.h, nothing gets recompiled. +16:02 <@sulix> Okay, just pushed support for click+drag and zoom in and out in the viewer. +16:03 <@sulix> (I did change the default precision to single, rather than half, as zoom out was totally broken with half-precision) +16:05 <@matches> The half precision implementation is broken itself anyway +16:07 <@matches> Hmm +16:07 <@matches> I can't seem to compile anymore +16:07 <@matches> Hang on +16:07 <@matches> That would be because `uname -i` reports "unknown" +16:12 <@matches> I have made unknown default to x86_64 :S +16:13 <@matches> I can see the precision issues! Good work +16:14 <@matches> These lecture notes seem useful: http://www.cs.berkeley.edu/~demmel/cs267/lecture21/lecture21.html +16:14 <@matches> Lecture notes > Blog post in terms of suitable reference? +16:16 <@sulix> It's got fortran in it, it must be suitably acedemic. +16:18 <@matches> Haha +16:18 <@matches> The VHDL compiler I am experimenting with uses Ada +16:18 <@sulix> I'm getting my fill of new languages by trying out some c++11 features. +16:20 <@sulix> I think I broak realtofloat by changing things to be single precision by default. +16:22 <@sulix> (Hopefully fixed) +16:49 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix +16:49 -!- Netsplit over, joins: @sulix +16:54 <@matches> What's with the netsplits +16:55 <@matches> You're on mussel? I'm on mantis? They are VMs on the same host? +16:55 <@matches> I don't know what this uniirc nonsense is +16:56 <@matches> What is "arctic" +16:56 -!- matches changed the topic of #ipdf to: Happy Bannana Netsplit +17:33 <@matches> Well I compiled the VHDL FPU +17:33 <@matches> It seems to work quite well +17:33 <@matches> Except for the part where it never actually finishes an operation +17:34 <@matches> One of the virtual transistors must have overheated +17:43 <@matches> Oops it might help to actually give it a valid operation +18:27 <@matches> Alright, so I'm going to experiment with getting our Real operations to run on the virtual FPU +18:28 <@matches> Then I can look into both hardware and software ways of getting arbitrary precision. +18:30 <@matches> VHDL appears to have text I/O so I could make everything read and write from pipes, but this seems like a terrible idea +18:30 <@matches> On the other hand the compiler is using Ada +19:21 <@matches> Oh wow +19:21 <@matches> To open stdout +19:22 <@matches> You pass it a string "STD_OUTPUT" for the filename +21:40 <@matches> Ok, I give up trying to link this thing +21:40 <@matches> fork() and exec() is seeming more and more elegant +22:11 <@matches> Nooo, buffering +22:11 <@matches> Ok, screw this +--- Day changed Thu Apr 10 2014 +00:00 <@matches> Note: Actually exec'ing the program instead of just going straight to "exit(EXIT_FAILURE)" is generally important +00:00 <@matches> Wall of text commit message incoming +00:01 <@matches> Horribly inefficient interface to virtual FPU sort of implemented +00:02 <@matches> I would have made it based on binary read/write rather than hex strings but I could not work out how to do that in VHDL +00:08 <@matches> I still can't believe what I have just done, it seems ludicrous +00:08 <@matches> Using an entire executable and stdio operations +00:08 <@matches> To do a floating point addition +00:10 <@matches> You should see how much is involved in compiling the VHDL FPU... +00:11 <@matches> I'm very pleased that it actually compiled from the version in jop's github without much effort, but still +00:11 <@matches> It's like 30 object files +00:11 <@matches> This is why it isn't in the code repo +00:19 <@matches> Whoops, there are some blatantly wrong comments in vfpu.cpp +00:19 <@matches> Oh well