IRC logs for #openrisc Monday, 2012-06-25

stekernfollowing how syscalls go from userspace through libc to the linux kernel is a not so easy task for the untrained eye (read my eye)...12:05
derRichard:D12:07
stekernI think I've got it now though ;)12:10
derRichardhow many system call entry points has openrisc? AFAIK only one. so, it's not that evil :P12:11
derRichardx86 is much more fun12:11
stekernyeah, it's not so bad, my main problem was to find out what function actually get's called when you call 'bind'12:12
stekernsome of the macro magic in there makes 'grep' a rather blunt weapon ;)12:14
* Jia always use grep instead of cscope&ctags12:17
derRichardstekern: bind is multiplexed12:23
derRichard(on most archs)12:23
stekernderRichard: what do you mean by 'multiplexed'?12:27
derRichardstekern: bind() is not a systemcall on most archs12:30
derRichardit's done via the socketcall system call12:30
stekernah, yes I understand what you mean12:33
derRichardAFAIK ia64 is the only arch where bind() is a real system clal12:34
juliusbAndrew Back asked me to do a bit of an interview recently about OpenCores and OpenRISC, he just put it up, if anyone is interested: http://www.designspark.com/content/community-insights-julius-baxter-openrisc12:47
stekernderRichard: regardless, I had to trace the bind through the socketcall syscall to find out where bind() actually is (again this would probably have been evident to the more trained linux eye) :)12:49
stekernjuliusb: nice! I'll read it more carefully later, but looked good at a quick glance12:50
TarekEldeebhello OR team :)15:20
TarekEldeeb...15:23
TEldeebjeremybennett, I'm online  .. :)15:41
jeremybennettTEldeeb: IIRC you were asking about implementing additional floating point support in OpenRISC and Or1ksim?15:54
TEldeebJeremybennett: Yes please...16:04
TEldeebi'd like to start with estimated performance gain with OR1200 as a platform16:05
TEldeebI tried to code a simple program to add two float arrays ..16:05
TEldeebthe FPU was never used ..16:05
TEldeebi used rtl simulation as described in trunk/orpsocv216:06
TEldeebi edited sw/Makefile.inc to enable # All hardware flags16:08
TEldeebMARCH_FLAGS ?=-mhard-mul -mhard-div -mhard-float16:08
TEldeebgot the same results ..16:08
TEldeebno FPU16:08
TEldeebwhat i am missing ..?? I want HW float opcodes ..16:08
jeremybennettTEldeeb: you really need one of the hardware guys to explain how to build Verilog with the hardware FPU and then extend that FPU.16:22
jeremybennettjuliusb is the expert16:22
TEldeeb:)16:32
TEldeebthanks16:32
juliusbmm, missed him17:15
stekernjuliusb: the de0_nano is actually pretty capable of running linux, the biggest problem is that there isn't enough storage space to store the image on-board18:20
juliusbah OK18:22
juliusbbut isn't it only like 8MB of RAM?18:22
juliusbor is it 16?18:22
jeremybennettYou can run OpenRISC linux in 8MB or RAM I believe - I think Or1ksim does that by default.18:22
stekernit has 32 MB of RAM18:25
stekernbut apart from that small fact-flaw, really good article!18:25
juliusbcool18:29
juliusbi'll remember that!18:29
juliusbit was very good of Andrew Back to offer me opportunity.18:30
stekernlooks like transparent union support is shaky in clang22:21
stekernwhen I compile busybox with clang/llvm I get a pointer-to-pointer reference to the sockaddr struct that should get passed to bind(), while gcc just passes the pointer to struct (as it should)22:23
stekernif I disable the transparent union in the header file bind() is declared, clang/llvm get it right as well22:24
derRichardtransparent union?22:50
derRichardstekern: you mean an anonymous union?22:51
stekernderRichard: no, I mean transparent union, take a look here: http://git.openrisc.net/cgit.cgi/jonas/uClibc/tree/include/sys/socket.h?h=master-next23:04
stekernaround lines 64-10023:04
derRichardah, another gcc extension i don't know :D23:13
stekernyeah, it was new to me too23:14
derRichardbut it sounds really usefull23:16
* derRichard reads the gcc manual23:16

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!