| -!- Jia_ is now known as Jia | 04:26 | |
| -!- Administrator is now known as Guest23590 | 04:39 | |
| juliusb | if an architeture has a set-if-equal comparison instruction, is there then no need for a set-if-not-equal instruction? | 13:03 |
|---|---|---|
| juliusb | strictly speaking | 13:03 |
| juliusb | if the set-if-equal writes 1 or 0 to a register | 13:03 |
| juliusb | then you don't need a set-if-not-equal do you? | 13:03 |
| juliusb | i'm assuming you have a branch-if-zero or branch-if-not-zero | 13:03 |
| juliusb | sorry, both a branch-if-zero _and_ branch-if-not-zero | 13:04 |
| jeremybennett | juliusb: Just forwarded you an email about the Cambridge LLVM social this evening in the Cambridge Blue | 13:08 |
| juliusb | Hi jeremybennett thanks for that | 13:13 |
| juliusb | I'm not on the LLVM mailing list, but will see if I can go along | 13:13 |
| stekern | juliusb: !(x == y) == (x != y), no? | 13:22 |
| juliusb | indeed, just double checking :) | 13:23 |
| juliusb | I'm thinking about or2k a little bit more lately and wanting to make the ISA a bit nicer | 13:23 |
| juliusb | it would be nice if we could have all of the most used instructions in 16-bit format | 13:23 |
| juliusb | or as many as possible | 13:23 |
| juliusb | I recall we thought that the idea of storing comparisons in registers is what you want to do to help with out of order execution and the like | 13:24 |
| stekern | mmm, l.bnf is a bit redundant, isnt it | 13:24 |
| juliusb | but that sucks becuase then you need 3-registers in an instruction | 13:25 |
| juliusb | unless you do a trick where the last rD is always the rB for the short comparison instruction | 13:25 |
| stekern | how does it help for out of order execution? (I'm not saying it does not) | 13:29 |
| juliusb | instead of storing your comparison results in a system-wide flag you can store it in a register | 13:29 |
| stekern | because you can do several comparisons? | 13:29 |
| stekern | ah, yes that was my guess | 13:29 |
| juliusb | and so reordered execution can then figure out where your intermediate result will be and determine if it's a hazard or not, whereas it will probably alwyas be a hazard if your flag is 'global' | 13:29 |
| juliusb | that was the reason given, anyway, i'm not the expert | 13:30 |
| stekern | yeah, well, only l.sfxxx sets the flag right? | 13:30 |
| stekern | in our current case | 13:30 |
| juliusb | yep | 13:31 |
| stekern | so only another l.sfxx instruction (or an instruction that would use the registers in the l.sfxx) would be a hazard, right? | 13:32 |
| juliusb | yep | 13:32 |
| juliusb | but they're probably quite frequent | 13:32 |
| stekern | yep ;) | 13:33 |
| juliusb | or a l.bx | 13:33 |
| juliusb | l.b[n]f | 13:33 |
| stekern | yes, of course, but a branch would end the reordering block anyway, right? | 13:33 |
| juliusb | i guess so | 13:34 |
| juliusb | but what if it doesn't? you could have gone ahead a few instructions, depending on what your branch prediction indicated is likely | 13:34 |
| juliusb | i'm more interested in optimisations for code density | 13:35 |
| juliusb | if almost all comparisons can be made as 16-bit instructions, and the branch is 16-bit, then i predict you save a bit of code space | 13:35 |
| stekern | that makes for pretty short branches, might not be a big problem though | 13:41 |
| juliusb | http://opencores.org/or2k/OR1K_Opcode_Analysis#Branch_distance | 13:43 |
| stekern | but don't we rather want l.beq, l.bgt etc? | 13:48 |
| juliusb | well, we could do that too | 14:01 |
| juliusb | but then you only have 3 bits of branch space | 14:03 |
| juliusb | so you have 3 options, 1) do the compare, store the result in an intermediate reg, then branch based on that result (zero or non-zero essentially) and be able to cover most addresses with your 7-bit (basically +-128 16-bit words) 2) do the compare, store it in a global flag, and then have more range in the 16-bit instruction or 3) do the compare-and-branch in a single instruction, but have almost no range (unless you ju | 14:06 |
| juliusb | or some other clever scheme | 14:11 |
| juliusb | i'm not proposing it's 16-bit only, of course, just that 32-bit instructions should be used sparingly, but if you ultimately need that much information to control the processor, you need it | 14:12 |
| juliusb | but i'm just wondering if we can cover most of the cases with a very compact and fast method | 14:12 |
| juliusb | essentially the set value in reg and then branch if it's zero or non-zero is a 32-bit instruction | 14:13 |
| juliusb | i'm just wondering if there's a trick where you can rely on the state of the CPU to save encoding what is largely redundent information in the instruction | 14:14 |
| juliusb | something like you always used the last destination regsiter as one of the source for the part | 14:15 |
| juliusb | or you always remember the last destination register for a comparison insn | 14:15 |
| juliusb | (i mean you always remember the last comparison destination register for your branch-if-[non-]zero | 14:16 |
| juliusb | but that's not really where you're struggling to get information in | 14:16 |
| juliusb | getting the comparison done in 16-bit is the annoying bit because you only have room for 2 registers and another 3-bit function field really | 14:16 |
| juliusb | and that function field is pmostly likely going to hold the type of comparison to do | 14:16 |
| juliusb | so unless you have a global flag, you're a bit screwed | 14:16 |
| juliusb | and that's the point at which you make the trade-off and say, well who cares about reordering, this is aiming to be an embedded cPU anyway, who's going to want to commit another million gates to get all the fancy reordering stuff for some potential performance win | 14:17 |
| juliusb | ... and you go back to your global flag idea | 14:18 |
| juliusb | :) | 14:18 |
| stekern | seperate compare and branch is 2 instructions compared to a combined compare and branch which is one, so 2x16 or 1x32 doesn't make much difference in code density | 14:18 |
| juliusb | exactly | 14:19 |
| stekern | but a compare and store in reg could be useful for other stuff than branch decisions, so I'm for that too (and that could very well be 16-bit) | 14:20 |
| stekern | example: if (a>b) return true; else return false; | 14:23 |
| juliusb | ya | 14:24 |
| stekern | ultimately, you could make it into conditional moves though (instead of just moving 1 or 0 into the reg) | 14:24 |
| stekern | but then you'd have to move 0 or 1 into registers before hand if that's what you want | 14:24 |
| juliusb | ya | 14:25 |
| juliusb | you sort of get it for free with a set-if-xyz | 14:25 |
| --- Log closed Wed May 16 14:39:45 2012 | ||
| --- Log opened Wed May 16 14:50:23 2012 | ||
| -!- Irssi: #openrisc: Total of 17 nicks [0 ops, 0 halfops, 0 voices, 17 normal] | 14:50 | |
| -!- Irssi: Join to #openrisc was synced in 22 secs | 14:50 | |
| --- Log closed Thu May 17 02:37:57 2012 | ||
| --- Log opened Thu May 17 02:43:31 2012 | ||
| -!- Irssi: #openrisc: Total of 17 nicks [0 ops, 0 halfops, 0 voices, 17 normal] | 02:43 | |
| -!- Irssi: Join to #openrisc was synced in 22 secs | 02:43 | |
| Jia | I've summited the qemu-or32 pacthes to qemu, and I hope we have qemu-or32 to use very soon :-) | 12:04 |
| Jia | lala, you are sleep... I'm going home. | 12:25 |
| juliusb | qemu submission begins here if anyone's interested: http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02394.html | 13:14 |
| * derRichard is already reading the source | 13:14 | |
| derRichard | very cool stuff! | 13:14 |
| juliusb | I can't really make head nor tail of it given I have no knowledge of how qemu works | 13:15 |
| juliusb | it looks thorough though | 13:15 |
| juliusb | did he actually get Linux running oni t? | 13:16 |
| juliusb | if so, that'd be wicked | 13:16 |
| juliusb | looks like he wrote the disassembly/decode stuff by hand! | 13:16 |
| juliusb | fpu supported too | 13:17 |
| juliusb | wow, looks like it handles delay slot exceptions properly | 13:18 |
| juliusb | at least, some attempt has been made, it probably works | 13:18 |
| juliusb | overflow and carry implemented! | 13:19 |
| juliusb | this thign looks the goods. I wonder how he tested it | 13:20 |
| juliusb | oh wow, I think he got linux userspace working | 13:23 |
| juliusb | ah i see, he's written a heap of test cases too | 13:25 |
| derRichard | btw: whats the status of gcc support? does it support dynamic linking? | 13:26 |
| juliusb | mmm, not that I know of | 13:27 |
| derRichard | dynamic linking would be nice to have | 13:27 |
| derRichard | to support glibc | 13:27 |
| juliusb | indeed | 13:31 |
| derRichard | is currently someone working on that? | 13:34 |
| juliusb | ummm, not sure | 13:35 |
| juliusb | there's a bit of the work done in some of the gcc port by guiseppe and I heard a while back that maybe some guys at SouthPole had it working | 13:35 |
| jeremybennett | derRichard: No dynamic linking yet. Most of the work is actually in binutils, not gcc. | 13:56 |
| derRichard | okay :) | 13:59 |
| derRichard | i'm wondering if i can use u-boot in this board: http://opencores.org/or1k/Ordb2a-ep4ce22 | 14:06 |
| derRichard | the orpmon bootloader sucks like hell | 14:06 |
| juliusb | haha i agree, and is the whoel reason I started the u-boot port | 14:23 |
| juliusb | you should be able to use it | 14:23 |
| juliusb | i don't know why ORSoC continue to use ORPmon | 14:23 |
| derRichard | can i start u-boot from gdb? (without flashing u-boot to my board) | 14:28 |
| juliusb | sure | 14:28 |
| derRichard | cool :) | 14:28 |
| juliusb | if you compile it to run out of RAM no worries | 14:28 |
| derRichard | good to know | 14:29 |
| * derRichard reads http://opencores.org/svnget,or1k?file=/trunk/docs/openrisc_arch.pdf | 16:02 | |
| derRichard | The state saved by the processor for each of the exceptions in Table 9-2 contains | 16:02 |
| derRichard | information that identifies the address of the failing instruction. Refer to the chapter | 16:02 |
| derRichard | entitled “Error! Reference source not found.” on page 错误!未定义书签。 for a | 16:02 |
| derRichard | more detailed description of exception processing. | 16:03 |
| derRichard | page 262 | 16:03 |
| jeremybennett_ | derRichard: Almost certainly it means Chapter 6 "Exception Model" | 16:10 |
| derRichard | yeah | 16:10 |
| jeremybennett_ | Possibly explicitly section 6.3 "Exception Processing" | 16:10 |
| derRichard | looke like the document was written in ms word | 16:10 |
| juliusb | derRichard: see the newer document, suffixed with _draft, in odt an pdf format | 16:11 |
| derRichard | juliusb: thx :) | 16:12 |
| derRichard | why does or1200 not have a cmpxchg instruction? | 16:23 |
| juliusb | cmpxchg? | 16:28 |
| juliusb | like compare-and-swap atomic thingo? | 16:28 |
| derRichard | jep | 16:28 |
| derRichard | juliusb: is this the most current u-boot for openrisc? git://openrisc.net/stefan/u-boot | 17:06 |
| stekern | derRichard: it is | 17:13 |
| derRichard | which branch? | 17:13 |
| stekern | master | 17:14 |
| derRichard | in the master branch i see only this board file: board/openrisc/openrisc-generic | 17:14 |
| derRichard | does it work with the ordb2a-ep4ce22 board? | 17:14 |
| stekern | ah, yes, the other boards are spread out | 17:16 |
| stekern | look at de0_nano for example | 17:16 |
| stekern | it's on my todo-list to get them more organized | 17:17 |
| stekern | the ordb2a board is not there, Lonetech is working on one I believe | 17:17 |
| derRichard | so my board will not work with uboot? :-( | 17:18 |
| stekern | well, it's not very hard work to do a board port | 17:18 |
| stekern | the thing that is not in there that Lonetech has been struggling with is the sd-card driver (I think) | 17:19 |
| derRichard | for now booting via tftp is ok | 17:19 |
| stekern | but for getting up a board with ethernet, I'd say it shouldn't take more than 15 minutes to copy the important parts from other boards | 17:20 |
| stekern | look at de0_nano and the atlys boards for reference | 17:20 |
| derRichard | okay. thanks! | 17:20 |
| stekern | I gotta run now, but I will be back later and check the backlog if you need guidance | 17:21 |
| derRichard | stekern: thanks a lot! | 17:21 |
| stekern | np ;) | 17:21 |
| derRichard | i hate or_debug_proxy so such, getting it working is always a PITA :) | 17:55 |
| juliusb | :( | 17:59 |
| juliusb | i can believe that | 17:59 |
| derRichard | or_debug_proxy seems to make use of a closed source library. is there no fully open source tool to use gdb with openrisc? | 18:03 |
| jeremybennett_ | derRichard: There is an open source library I believe, but no one has got it working. | 18:04 |
| derRichard | hm, sad. the current closed source library seems to make use of /proc/bus/usb/ on linux which is turned off on most recent distros | 18:07 |
| derRichard | and it's x86_32 only | 18:07 |
| stekern | derRichard: openocd is using the open source ftdi driver | 18:18 |
| derRichard | can i use openocd on my board? | 18:19 |
| stekern | I'm not sure | 18:19 |
| stekern | but isn't there a ftdi chip connected to the debug port on that board? | 18:22 |
| derRichard | yeah, seems so | 18:23 |
| jeremybennett_ | I'm sure when Julius first did or_debug_proxy there was stuff about using open source libraries instead (libusb?) for it. | 18:23 |
| jeremybennett_ | I think the FTDI site may even have pointed you at the code but took no responsibility for it. | 18:23 |
| derRichard | stekern: btw: u-boot for the de0_nano does not build: http://paste.opensuse.org/view/raw/36624249 | 18:28 |
| stekern | derRichard: hmm, it builds fine here, how do you build it? | 18:41 |
| derRichard | make de0_nano_config && make | 18:41 |
| derRichard | ordb1a3pe1500 builds fine | 18:41 |
| stekern | try running: make distclean && make de0_nano | 18:42 |
| derRichard | w00t! | 18:42 |
| derRichard | why did make de0_nano_config && make not work? | 18:43 |
| derRichard | i'm using the make BOARD_config way for lots of other boards too | 18:43 |
| stekern | that should work, my guess is that it was the make distclean that made the difference | 18:43 |
| derRichard | hmm, openocd is unable to find my device/board | 18:51 |
| derRichard | Debug: 139 17 ft2232.c:2364 ft2232_init_libftdi(): 'ft2232' interface using libftdi with 'orsoc-jtag' layout (0403:6010) | 18:51 |
| derRichard | Error: 140 187 ft2232.c:2386 ft2232_init_libftdi(): unable to open ftdi device: device not found | 18:51 |
| derRichard | Debug: 141 187 command.c:638 run_command(): Command failed with error code -100 | 18:51 |
| derRichard | stekern: u-boot works so far with the de0_nano config | 19:11 |
| derRichard | now it's time to get ethernet working | 19:11 |
| gxti | something to look out for if you have a gigabit PHY is that the MAC doesn't seem to support gigabit operation but it does not instruct the PHY to down-negotiate | 19:28 |
| gxti | i spent a while banging my head into that one :) | 19:29 |
| derRichard | hehe | 19:29 |
| derRichard | my current problem is that u-boot won't build with CONFIG_ETHOC enabled | 19:30 |
| derRichard | *grr* there was a hidden #undef CONFIG_CMD_NET | 19:31 |
| derRichard | that explains why my #define CONFIG_CMD_NET did not work :D | 19:31 |
| derRichard | stekern: i think we need this quirk http://opencores.org/forum,OpenRISC,0,4750 too | 19:43 |
| * derRichard reads drivers/net/ethoc.c | 19:43 | |
| stekern | isn't that phy dependent? | 19:55 |
| stekern | (just quickly read the forum thread) | 19:55 |
| derRichard | hmm, true | 19:58 |
| stekern | anyways, I assume there is some mdio command to fiddle with phy regs in u-boot | 19:59 |
| stekern | I have never tried myself | 20:01 |
| derRichard | why does include/configs/openrisc-generic.h not set and phy related CONFIG? | 20:06 |
| * derRichard is confused | 20:06 | |
| stekern | I don't think any board set any phy related config | 20:10 |
| derRichard | this is maybe a very stupid question, is the ethernet chip (this ethoc thingy) part of the openrisc softcore? IOW is it on the fpga? | 21:05 |
| gxti | the PHY is a separate IC, the MAC is in RTL | 21:07 |
| derRichard | why do you call it "MAC"? isn't is a FEC? (fast ethernet controller) | 21:07 |
| gxti | MAC stands for media access controller, it's the interface between the CPU and a logic-only representation of the raw ethernet stream | 21:09 |
| -!- Netsplit *.net <-> *.split quits: dwhite | 21:10 | |
| derRichard | gxti: hmm, this is confusing. where is this mac thing described? if i want to write my own ethernet driver for it. where is the register description? | 21:16 |
| gxti | derRichard: are you using orpsoc? | 21:17 |
| gxti | in orpsoc it's in rtl/verilog/ethmac | 21:18 |
| derRichard | i'm using this board http://opencores.org/or1k/Ordb2a-ep4ce22 | 21:28 |
| derRichard | i'm not sure what exactly runs on it | 21:28 |
| derRichard | gxti: yes it's ORPSoCv2 | 21:35 |
| derRichard | now i understand | 21:35 |
| derRichard | openrisc 1000 the architekture, openrisc 1200 is an implementation of it. and orpsoc is a soc which uses the openrisc 1200 cpu core | 21:36 |
| derRichard | *very* confusing :P | 21:36 |
| derRichard | do we have a linux driver for this spi master? http://opencores.org/project,simple_spi | 22:32 |
| _franck_ | hi derRichard : look here http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/spi/spi_opencores.c | 23:06 |
| derRichard | *grrr*, why is this driver not mainline? | 23:07 |
| _franck_ | don't know.... | 23:07 |
| derRichard | jonibo: ^^^ why is your opencores spi driver not mainline? | 23:08 |
| derRichard | same question on drivers/usb/host/ohs900-hcd.c | 23:10 |
| _franck_ | may because it hasn't been submited :) | 23:10 |
| derRichard | jonas is the openrisc architekture maintainer, it his "job" :P | 23:11 |
| derRichard | anyway, i can also bring the drivers mainline. they look good | 23:12 |
| _franck_ | derRichard: as you're using an altera board, you could try my tcl download if you want to easily download and run an elf | 23:18 |
| _franck_ | http://github.com/Franck79/or1k-tcltools | 23:18 |
| derRichard | "an elf" in terms of a bare metal elf file? | 23:19 |
| _franck_ | yes | 23:19 |
| derRichard | i'm more interested in a linux board support package | 23:19 |
| _franck_ | ok :) | 23:20 |
| derRichard | IOW a sane boot loader (not this orpmon thing) plus kernel (with driver) and userspace | 23:20 |
| gxti | i managed to get orpsoc running on atlys with very little experience in this general area, however wiring in new stuff is for the moment beyond my knowledge | 23:24 |
| gxti | atlys being already a supported board of course | 23:24 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!