<taylan>ecraven: dsmith: what is the purpose of this sign-extending or zero-extending? <dsmith>taylan: You have an smaller bit value that needs to be placesd into a register with more bits. What do yout fill the "empty" bits with? <taylan>dsmith: I would guess it doesn't matter, since they will be masked out anyway? <dsmith>taylan: If you have an immidiate value, say "3". Why take up 32 or 64 bits of code when 8 will do? <dsmith>IIRC on arm, there are no 32 bit immediates, you need to use two 16 bit immediates. (or is that 64 and 32?) <dsmith>arm has some really wacky immediates. There was a nasty bug some of us were working on about a year ago. <dsmith>IF you wanted to load 00xx00xx00xx00xx, where "xx" was the same, there special bits that do that with only haveing the "xx" in the opcode. <dsmith>It was actually a jump or branch, iirc. <dsmith>So -3 in twos-compliment in 8 bits is 0xfd, in 64 bits it's 0xfffffffffffffffd, if you want to load -3 into a 64bit registere, you gotta sign extend. 0x00000000000000fd is NOT -3 it's 253 or something. <dsmith>So the simple rule is, unsigned: use zero-fill, signed: use sign-extend. <dsmith>taylan: Thank *you* for stomping on all those bugs! ***KindOne_ is now known as KindOne
***rekado_ is now known as rekado
***roptat_ is now known as roptat
<apteryx>is there a way to see which architecture a .go was compiled for? objdump says the architecture is 'architecture: UNKNOWN!, flags 0x00000150' <dsmith>apteryx: "file" doesn't show that either. <dsmith>apteryx: At one time, I had some rules for old-format .go files. <apteryx>also, this still confuses me, why are .go target-specific? I thought they were targetting the Guile VM (being byte-compiled), with VMs being typically target-agnostic (that's their point, no?) <spacebat1>is there a package manager for guile? guildhall seems quite old - I see a nice list of libraries on the guile website, which says they are gleaned from guix, but I can't run guix on MacOS <apteryx>spacebat1: Guix is one option (it's not Guile-specific, but it's written in Scheme/Guile :-)) <spacebat1>I can't use guix though, unless there is a way to run it on OSX <spacebat1>maybe you run it in a container and have it install to the macos filesystem <spacebat1>so that you can get to the artefacts directly running guile on macos, but that sounds dodgy <spacebat1>how do people normally manage their dependencies in guile projects? write a makefile target that checks them out using git? ***bsima1 is now known as bsima
<dsmith>apteryx: There are 4 diferent "targets" in .go files: the combinations of 64bit/32bit and bigendian/littleendian. <dsmith>So th same 32-LE .go file runs fine on 32bit intel and also, say, mipsel. <dsmith>file on my laptop shows "64-bit LSB", and on my beaglebone black "32-bit LSB" <dsmith>Yes! The big endian versions show "MSB" instead of "LSB" <dsmith>apteryx: So there you go. You *can* see what "arch" a .go file was compiled for. <leoprikler>spacebat1: the overlap between guile and guix is big. Other than that, most Guile stuff uses Autotools, so you ought to be safe if you check out all your dependencies and run `make install` <dsmith>apteryx: Also, those old-format go files were also of just 4 kinds {64,32}-{B,L}E , but were not ELF. <apteryx>dsmith: Thanks a lot for explaining! Using the 'file' utility I can see this too now. <apteryx>Now wondering if this is Guile-specific; I'm guessing other byte-compiled languages such as Python (.pyc) files would have to solve that problem too, but I haven't been exposed to it yet. ***efftee is now known as ft
<dsmith>apteryx: iiuc, pyc files are arch idependent, but not version independent. <RhodiumToad>a common technique (I don't know what python does) is to have a magic identifying string that includes any important details. going full ELF as guile does seems not to be common <dsmith>Yeah, I've never heard ELF used for anything but .so's and executables. <taylan>I only now realize that the numbered slot references in disassembled bytecode, e.g. (make-immediate <slot> <value>), are backwards from the max slot. so 0 is the last slot, N the first. terribly confusing :\ <taylan>(it's because of the downward-growing stack) <RhodiumToad>ELF has the advantage that there's a lot of tools, but it's also a whole lot more complex than most languages would ever need <dsmith>taylan: Making any more progess? <taylan>dsmith: very slowly, trying to grok everything at every step :D <dsmith>There is a very nice text diagram in the comments of one of the source files. <taylan>I saw it, it's in the info manual too, but it's a little misleading as it shows the slots numbered top down, but the slot references in disassembly are the other way around <taylan>the fourth last paragraph in the manual actually explains this but I had missed it until now <taylan>fifth last and fourth last, rather <taylan>are negative pointer references actually slower than positive ones? seeing slot references 0 to -N would have been less confusing than N to 0 IMO. <taylan>(using the frame pointer instead of the stack pointer as the base) ***KindOne_ is now known as KindOne
***bjoli is now known as manumanumanu
<manumanumanu>Does "potentially unbound variable" warnings warn before DCE? <dsmith>civodul: Wow. Inlcudes a heisenbug. <taylan>civodul: yeah I think that's in debbugs already, let me check <taylan>I see Marius already referenced that bug in the Guix report <RhodiumToad>is there a self-contained example of that? I haven't managed to reproduce yet <dsmith>I wonder if swapping the args to eq? changes things, since swapping the and sub-expressions did. As in (eq? 'detailed-status action) <leoprikler>Can someone tell me what can get GC to deadlock in pthread_cond_wait? <leoprikler>call-with-trace does not seem very helpful, it barfs on FFI stuff