IRC logs for #openrisc Wednesday, 2012-05-16

-!- Jia_ is now known as Jia04:26
-!- Administrator is now known as Guest2359004:39
juliusbif an architeture has a set-if-equal comparison instruction, is there then no need for a set-if-not-equal instruction?13:03
juliusbstrictly speaking13:03
juliusbif the set-if-equal writes 1 or 0 to a register13:03
juliusbthen you don't need a set-if-not-equal do you?13:03
juliusbi'm assuming you have a branch-if-zero or branch-if-not-zero13:03
juliusbsorry, both a branch-if-zero _and_ branch-if-not-zero13:04
jeremybennettjuliusb: Just forwarded you an email about the Cambridge LLVM social this evening in the Cambridge Blue13:08
juliusbHi jeremybennett thanks for that13:13
juliusbI'm not on the LLVM mailing list, but will see if I can go along13:13
stekernjuliusb: !(x == y) == (x != y), no?13:22
juliusbindeed, just double checking :)13:23
juliusbI'm thinking about or2k a little bit more lately and wanting to make the ISA a bit nicer13:23
juliusbit would be nice if we could have all of the most used instructions in 16-bit format13:23
juliusbor as many as possible13:23
juliusbI 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 like13:24
stekernmmm, l.bnf is a bit redundant, isnt it13:24
juliusbbut that sucks becuase then you need 3-registers in an instruction13:25
juliusbunless you do a trick where the last rD is always the rB for the short comparison instruction13:25
stekernhow does it help for out of order execution? (I'm not saying it does not)13:29
juliusbinstead of storing your comparison results in a system-wide flag you can store it in a register13:29
stekernbecause you can do several comparisons?13:29
stekernah, yes that was my guess13:29
juliusband 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
juliusbthat was the reason given, anyway, i'm not the expert13:30
stekernyeah, well, only l.sfxxx sets the flag right?13:30
stekernin our current case13:30
stekernso only another l.sfxx instruction (or an instruction that would use the registers in the l.sfxx) would be a hazard, right?13:32
juliusbbut they're probably quite frequent13:32
stekernyep ;)13:33
juliusbor a l.bx13:33
stekernyes, of course, but a branch would end the reordering block anyway, right?13:33
juliusbi guess so13:34
juliusbbut what if it doesn't? you could have gone ahead a few instructions, depending on what your branch prediction indicated is likely13:34
juliusbi'm more interested in optimisations for code density13:35
juliusbif 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 space13:35
stekernthat makes for pretty short branches, might not be a big problem though13:41
stekernbut don't we rather want l.beq, l.bgt etc?13:48
juliusbwell, we could do that too14:01
juliusbbut then you only have 3 bits of branch space14:03
juliusbso 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 ju14:06
juliusbor some other clever scheme14:11
juliusbi'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 it14:12
juliusbbut i'm just wondering if we can cover most of the cases with a very compact and fast method14:12
juliusbessentially the set value in reg and then branch if it's zero or non-zero is a 32-bit instruction14:13
juliusbi'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 instruction14:14
juliusbsomething like you always used the last destination regsiter as one of the source for the part14:15
juliusbor you always remember the last destination register for a comparison insn14:15
juliusb(i mean you always remember the last comparison destination register for your branch-if-[non-]zero14:16
juliusbbut that's not really where you're struggling to get information in14:16
juliusbgetting the comparison done in 16-bit is the annoying bit because you only have room for 2 registers and another 3-bit function field really14:16
juliusband that function field is pmostly likely going to hold the type of comparison to do14:16
juliusbso unless you have a global flag, you're a bit screwed14:16
juliusband 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 win14:17
juliusb... and you go back to your global flag idea14:18
stekernseperate 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 density14:18
stekernbut 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
stekernexample: if (a>b) return true; else return false;14:23
stekernultimately, you could make it into conditional moves though (instead of just moving 1 or 0 into the reg)14:24
stekernbut then you'd have to move 0 or 1 into registers before hand if that's what you want14:24
juliusbyou sort of get it for free with a set-if-xyz14: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 secs14: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 secs02:43
JiaI've summited the qemu-or32 pacthes to qemu, and I hope we have qemu-or32 to use very soon :-)12:04
Jialala, you are sleep... I'm going home.12:25
juliusbqemu submission begins here if anyone's interested:
* derRichard is already reading the source13:14
derRichardvery cool stuff!13:14
juliusbI can't really make head nor tail of it given I have no knowledge of how qemu works13:15
juliusbit looks thorough though13:15
juliusbdid he actually get Linux running oni t?13:16
juliusbif so, that'd be wicked13:16
juliusblooks like he wrote the disassembly/decode stuff by hand!13:16
juliusbfpu supported too13:17
juliusbwow, looks like it handles delay slot exceptions properly13:18
juliusbat least, some attempt has been made, it probably works13:18
juliusboverflow and carry implemented!13:19
juliusbthis thign looks the goods. I wonder how he tested it13:20
juliusboh wow, I think he got linux userspace working13:23
juliusbah i see, he's written a heap of test cases too13:25
derRichardbtw: whats the status of gcc support? does it support dynamic linking?13:26
juliusbmmm, not that I know of13:27
derRicharddynamic linking would be nice to have13:27
derRichardto support glibc13:27
derRichardis currently someone working on that?13:34
juliusbummm, not sure13:35
juliusbthere'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 working13:35
jeremybennettderRichard: No dynamic linking yet. Most of the work is actually in binutils, not gcc.13:56
derRichardokay :)13:59
derRichardi'm wondering if i can use u-boot in this board:
derRichardthe orpmon bootloader sucks like hell14:06
juliusbhaha i agree, and is the whoel reason I started the u-boot port14:23
juliusbyou should be able to use it14:23
juliusbi don't know why ORSoC continue to use ORPmon14:23
derRichardcan i start u-boot from gdb? (without flashing u-boot to my board)14:28
derRichardcool :)14:28
juliusbif you compile it to run out of RAM no worries14:28
derRichardgood to know14:29
* derRichard reads,or1k?file=/trunk/docs/openrisc_arch.pdf16:02
derRichardThe state saved by the processor for each of the exceptions in Table 9-2 contains16:02
derRichardinformation that identifies the address of the failing instruction. Refer to the chapter16:02
derRichardentitled “Error! Reference source not found.” on page 错误!未定义书签。 for a16:02
derRichardmore detailed description of exception processing.16:03
derRichardpage 26216:03
jeremybennett_derRichard: Almost certainly it means Chapter 6 "Exception Model"16:10
jeremybennett_Possibly explicitly section 6.3 "Exception Processing"16:10
derRichardlooke like the document was written in ms word16:10
juliusbderRichard: see the newer document, suffixed with _draft, in odt an pdf format16:11
derRichardjuliusb: thx :)16:12
derRichardwhy does or1200 not have a cmpxchg instruction?16:23
juliusblike compare-and-swap atomic thingo?16:28
derRichardjuliusb: is this the most current u-boot for openrisc? git://
stekernderRichard: it is17:13
derRichardwhich branch?17:13
derRichardin the master branch i see only this board file: board/openrisc/openrisc-generic17:14
derRicharddoes it work with the ordb2a-ep4ce22 board?17:14
stekernah, yes, the other boards are spread out17:16
stekernlook at de0_nano for example17:16
stekernit's on my todo-list to get them more organized17:17
stekernthe ordb2a board is not there, Lonetech is working on one I believe17:17
derRichardso my board will not work with uboot? :-(17:18
stekernwell, it's not very hard work to do a board port17:18
stekernthe thing that is not in there that Lonetech has been struggling with is the sd-card driver (I think)17:19
derRichardfor now booting via tftp is ok17:19
stekernbut 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 boards17:20
stekernlook at de0_nano and the atlys boards for reference17:20
derRichardokay. thanks!17:20
stekernI gotta run now, but I will be back later and check the backlog if you need guidance17:21
derRichardstekern: thanks a lot!17:21
stekernnp ;)17:21
derRichardi hate or_debug_proxy so such, getting it working is always a PITA :)17:55
juliusbi can believe that17:59
derRichardor_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
derRichardhm, sad. the current closed source library seems to make use of /proc/bus/usb/ on linux which is turned off on most recent distros18:07
derRichardand it's x86_32 only18:07
stekernderRichard: openocd is using the open source ftdi driver18:18
derRichardcan i use openocd on my board?18:19
stekernI'm not sure18:19
stekernbut isn't there a ftdi chip connected to the debug port on that board?18:22
derRichardyeah, seems so18: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
derRichardstekern: btw: u-boot for the de0_nano does not build:
stekernderRichard: hmm, it builds fine here, how do you build it?18:41
derRichardmake de0_nano_config && make18:41
derRichardordb1a3pe1500 builds fine18:41
stekerntry running: make distclean && make de0_nano18:42
derRichardwhy did make de0_nano_config && make not work?18:43
derRichardi'm using the make BOARD_config way for lots of other boards too18:43
stekernthat should work, my guess is that it was the make distclean that made the difference18:43
derRichardhmm, openocd is unable to find my device/board18:51
derRichardDebug: 139 17 ft2232.c:2364 ft2232_init_libftdi(): 'ft2232' interface using libftdi with 'orsoc-jtag' layout (0403:6010)18:51
derRichardError: 140 187 ft2232.c:2386 ft2232_init_libftdi(): unable to open ftdi device: device not found18:51
derRichardDebug: 141 187 command.c:638 run_command(): Command failed with error code -10018:51
derRichardstekern: u-boot works so far with the de0_nano config19:11
derRichardnow it's time to get ethernet working19:11
gxtisomething 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-negotiate19:28
gxtii spent a while banging my head into that one :)19:29
derRichardmy current problem is that u-boot won't build with CONFIG_ETHOC enabled19:30
derRichard*grr* there was a hidden #undef CONFIG_CMD_NET19:31
derRichardthat explains why my #define CONFIG_CMD_NET did not work :D19:31
derRichardstekern: i think we need this quirk,OpenRISC,0,4750 too19:43
* derRichard reads drivers/net/ethoc.c19:43
stekernisn't that phy dependent?19:55
stekern(just quickly read the forum thread)19:55
derRichardhmm, true19:58
stekernanyways, I assume there is some mdio command to fiddle with phy regs in u-boot19:59
stekernI have never tried myself20:01
derRichardwhy does include/configs/openrisc-generic.h not set and phy related CONFIG?20:06
* derRichard is confused20:06
stekernI don't think any board set any phy related config20:10
derRichardthis 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
gxtithe PHY is a separate IC, the MAC is in RTL21:07
derRichardwhy do you call it "MAC"? isn't is a FEC? (fast ethernet controller)21:07
gxtiMAC stands for media access controller, it's the interface between the CPU and a logic-only representation of the raw ethernet stream21:09
-!- Netsplit *.net <-> *.split quits: dwhite21:10
derRichardgxti: 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
gxtiderRichard: are you using orpsoc?21:17
gxtiin orpsoc it's in rtl/verilog/ethmac21:18
derRichardi'm using this board
derRichardi'm not sure what exactly runs on it21:28
derRichardgxti: yes it's ORPSoCv221:35
derRichardnow i understand21:35
derRichardopenrisc 1000 the architekture, openrisc 1200 is an implementation of it. and orpsoc is a soc which uses the openrisc 1200 cpu core21:36
derRichard*very* confusing :P21:36
derRicharddo we have a linux driver for this spi master?,simple_spi22:32
_franck_hi derRichard : look here
derRichard*grrr*, why is this driver not mainline?23:07
_franck_don't know....23:07
derRichardjonibo: ^^^ why is your opencores spi driver not mainline?23:08
derRichardsame question on drivers/usb/host/ohs900-hcd.c23:10
_franck_may because it hasn't been submited :)23:10
derRichardjonas is the openrisc architekture maintainer, it his "job" :P23:11
derRichardanyway, i can also bring the drivers mainline. they look good23: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 elf23:18
derRichard"an elf" in terms of a bare metal elf file?23:19
derRichardi'm more interested in a linux board support package23:19
_franck_ok :)23:20
derRichardIOW a sane boot loader (not this orpmon thing) plus kernel (with driver) and userspace23:20
gxtii 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 knowledge23:24
gxtiatlys being already a supported board of course23:24

Generated by 2.15.2 by Marius Gedminas - find it at!