| |
| |
| |
|
Page: 1 2 3
<BobtheAvenger> i wanna get onto powerPC stuff
<BobtheAvenger> maybe when i get back
<lars_-> hi. how would i go about measuring a sound level on soundcard out (on windows)?
<Inside> O-o
<Inside> That's not an ASM question, is it?
<lars_-> what makes you think so?
<lars_-> i want to fetch sound level in real time in asm
<libero_> lars_-, i guess u need to access the sound driver directly
<libero_> which is OS dependant
<imaginator> I'm having problems with idivl in an inline asm macro. I'm using it to hopefully get a faster div() (a bottleneck in my bitmap code). I'm getting a floating point error when I use it in a more complex function.
<imaginator> here is my test app http://rafb.net/paste/results/hlQKB296.html
<imaginator> oddly gcc won't let me use : "eax", "ecx", etc. in the clobber list
<imaginator> for example with : "eax" I get "x86_div_inline.c:18: error: can't find a register in cl*** `AREG' while reloading `asm'"
<imaginator> but another odd thing is that I can do "ebp" any hints?
<imaginator> I found part of the answer: "You may not write a clobber description in a way that overlaps with an input or output operand."
<imaginator> I still don't know why the floating point exception occurs when I'm not even using FP, or any clobber list.
<iojkl_> hello
<imaginator> hello
<imaginator> regarding my earlier question; I think I found a solution that works http://rafb.net/paste/results/sIaory33.html now my test suite p***es too.
<xark> imaginator: Ahh, you found the "secret" names of x86 registers for clobbers. :)
<imaginator> this reduced the time according to gprof, so I'm somewhat happy, even though I have more to optimize
<imaginator> xark :)
<xark> imaginator: What system? Linux?
<imaginator> netbsd
<xark> Ahh. Does valgrind work under that OS?
<imaginator> I think only freebsd has valgrind working among the bsds
<xark> ...sadly I think not.
<xark> Oh well. Great program for showing cache usage (and some other hard to get stats).
<imaginator> I could use my ISP's linux box, but I'm not sure if I have enough space left in my quota to fit valgrind
<imaginator> I'm already using 80416 blocks out of 102400/100 MiB :(
<xark> Hehe, bzip2 up some stuff. :)
<xark> Its probably not worth going crazy for, but it is a nice utility (mostly for memory leak/purity testing).
<tid-wave> hello! is it worth learning HLA ? (from the AoA book)
<prolific> Nope
<prolific> If you want to create real programs with ***embly, then -possibly-. If you want to learn ***embly, arch, and the way the systems, then most likely not
<prolific> systems work*
<tid-wave> so AoA is not a good book ?
<markos_64> hmm... any development going on with nasm?
<prolific> tid-wave, It could be. I just wouldn't advise learning HLA
<prolific> tid-wave, I'd suggest "Programming From the Ground Up". I think it's the first url in the topic. If not you can search for it; it's very popular
<prolific> Er it's the "perfect linux ***embly book". Of course, that's if you're coding in linux :)
<tid-wave> prolific thanks for the information
<prolific> tid-wave, Sure
<markos_64> soo... any linux ***embler out there with intel syntax and TLS support?
<undesktop> gas, nasm
<Malebranche> fasm ;)
<markos_64> nasm and TLS?
<markos_64> (TLS == thread-local support for ELF)
<markos_64> does fasm support it?
<Malebranche> i have to take a look...
<undesktop> TLS isn't dependend from the ***embler
<undesktop> it's just an OS/ELF mechanism
<undesktop> an ***embler doesn't care about TLS
<markos_64> ELF mechanism
<markos_64> and ELF needs special relocation, section and symbol types to suppport it
<markos_64> that have to be generated by ***embler
<undesktop> hm yes, you're right
<undesktop> but it should help to just use the GNU LD
<markos_64> i am using GNU ld
<markos_64> but it needs TLS symbols on input
<markos_64> and special relocations, too
<markos_64> so... should i stop being lazy and make a patch?
<undesktop> so it isn't possible to use TLS from a compiler/***embler that isn't TLS aware?
<markos_64> exactly.
<undesktop> strange, theoretically it should still be possible; by exporting the TLS section offsets somehow...
<markos_64> yeah
<markos_64> but you still have to declare these offsets as TLS symbols
<markos_64> and you have to declare section as TLS section
<markos_64> there are flags for it
<markos_64> and ELF uses very special relocation types
<undesktop> you still could declare these symbols in C files... but it shouldn't be too hard to hack this into an ***embler...
<markos_64> yeah, but i want to reference them from asm
<markos_64> so making c file with "__thread int foo;" won't solve the problem
<undesktop> yeah, I see, it refuses to link
<undesktop> fuzzy!
<Trinsic> anyone here work on heavily self modded code in asm before?
<markos_64> http://people.redhat.com/drepper/tls.pdf
<Robert> Trinsic: Mmm...6502
<markos_64> this is the specification
<undesktop> of course you still could reserve a large enough TLS region in C code and get a pointer to it by a C function, but I guess that wouldn't be so great
<Trinsic> Robert, thats what I am contomplating programming for, well, the 6510 (c64)
<markos_64> indeed.
<Robert> Trinsic: Ah. :)
<Trinsic> Robert, which platform using the 6502?
<Robert> Trinsic: What are you coding?
<Robert> Trinsic: Well, I was refering to the 6510... but I think the Apple II uses the old 6502e
<Trinsic> Robert, a interactive fiction type interface.
<Robert> 6502.*
<Robert> Fiction type?
<Trinsic> i am thinking about making the memory handler copy objects but at the same time expand the objects.
<Trinsic> makybe i'll just make it copy object then expand, without modifying the source.
<Trinsic> Robert, well not neccesirly.. more like a MOO or MUD type interface.
<Robert> Ah, OK.
<Trinsic> i haven't really sorted all the code for it yet.
<Robert> "go north", "start tape", "freak out"
<markos_64> okau. doing a patch for nasm.
<Robert> Heading for the shower, brb.
<undesktop> markos_64: and you're sure gas doesn't support it?
<undesktop> since gcc uses gas, it's very likely that gas has support for TLS
<markos_64> undesktop: gas indeed supports it. but gas syntax ****s.
<undesktop> yeah, but gas can switch to intel syntax
<markos_64> intel syntax? pffft
<undesktop> (however, it still ****s with intel syntax)
<markos_64> indeed.
<markos_64> i want real intel syntax
<markos_64> not just at&t with reversed params
<markos_64> hmm... i can set a small bitfield here...
<undesktop> for what do you need TLS in ***embler anyway?
<markos_64> errno handling
<markos_64> rewriting some libc functions
<undesktop> setting the errno with a C function shouldn't hurt, should it?
<undesktop> for what is __gxx_personality_v0 when linking g++ Code?
<markos_64> hmmm... i guess some sort of exception hnadling function from libgcc
<markos_64> or lib++
<markos_64> er, libg++
<markos_64> or however it's called
<undesktop> or ABI stuff
<markos_64> personality is some helper funtion for stack unwinding IIRC
<undesktop> urg, and linking with libsupc++ wants the _Unwind_* functions
<markos_64> yeah. c++ ABI wants HELL of helper functions
<markos_64> ewwww.... this will be soooo ugly construct...
<undesktop> I just wanted to convert my Gnu99 sources to C++, but... too much problems
<markos_64> nearly got some TLS stuff and weak symbols working :)
<markos_64> though with some really ugly constructs here and there...
<undesktop> btw, when it comes to Linux and TLS, I love to cite this quote: https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2004-November/001091.html
<markos_64> heh
<markos_64> hum... another ugly kludge
<markos_64> alright. if i'm lucky, it should work now
<undesktop> did you hack an ***embler?
<markos_64> aye
<markos_64> segfault.
<markos_64> **** happens
<Robert> Hah.
<Robert> Get used to it.
<markos_64> fixed
<markos_64> now, it compiles... but still thinks that my weak symbols are simply global
<markos_64> Segmentation fault - core dumped.
<markos_64> but...
<markos_64> local symbols with special flags now work
<markos_64> and that means proper support for TLS variables
<undesktop> nice
<markos_64> segfault seems to be with weak symbols
<markos_64> now, i only have one relocation symbol out of like ten
<markos_64> for TLS
<zoly> g'day
<Robert> God dag, zoly.
<zoly> hi rob
<zoly> _ert
<markos_64> YEEHAW
Return to asm
or
Go to some related
logs:
politics
chatzone
"solaris 2.5.1 x86" dca"
|
|