#avr Logs
May 12 2018
#avr Calendar
12:08 AM day__ is now known as day
12:34 AM rue_mohr: anyone have a fast way to find the highest set bit in a word?
12:37 AM Tom_itx: https://stackoverflow.com/questions/671815/what-is-the-fastest-most-efficient-way-to-find-the-highest-set-bit-msb-in-an-i?noredirect=1&lq=1
12:38 AM Tom_itx: https://www.geeksforgeeks.org/find-significant-set-bit-number/
12:39 AM Tom_L: probably gonna have to loop thru and compare
12:40 AM Ameisen: the alternate __[u]int sizes appear to be working, at least
12:40 AM Ameisen: I doubt they're quiiite as efficient as the normal ones since they won't have custom reduction code
12:41 AM Ameisen: I _should_ be able to get float16 working, as GCC has support for it built-in, just hard to expose
12:41 AM Ameisen: float24 requires a bit more work
01:19 AM rue_mohr: ok
01:20 AM rue_mohr: to point to an item in a list of 0 things, I need 0 bits
01:20 AM rue_mohr: to point to an item in a list of 1 things, I need 0 bits ???
01:20 AM rue_mohr: to point to an item in a list of 2 things, I need 1 bits ???
01:20 AM rue_mohr: to point to an item in a list of 3 things, I need 2 bits
01:21 AM rue_mohr: to point to an item in a list of 4 things, I need 2 bits
01:21 AM rue_mohr: to point to an item in a list of 5 things, I need 3 bits
01:21 AM rue_mohr: that initial bit hurts my head
01:22 AM rue_mohr: if I only have one thing in a list, I need 0 bits to specify which item it is, cause its always going to be that item
01:22 AM rue_mohr: if the list has zero things in it, I need 0 bits cause its always going to be nothing
01:22 AM rue_mohr: if I have 2 things, i need 1 bit
01:25 AM rue_mohr: 0 -> 0
01:25 AM rue_mohr: 1 -> 0
01:25 AM rue_mohr: 2 -> 1
01:25 AM rue_mohr: 3 -> 2
01:25 AM rue_mohr: 4 -> 2
01:25 AM rue_mohr: 5 -> 3
01:25 AM rue_mohr: 6 -> 3
01:25 AM rue_mohr: 7 -> 3
01:25 AM rue_mohr: 8 -> 3
01:25 AM rue_mohr: 9 -> 4
01:25 AM rue_mohr: I really think that 1 thing should require 1 bit, but the math says no.
01:26 AM rue_mohr: I suppose the bit would always be clear
01:26 AM rue_mohr: because index 1 dosn't exist, just index 0
01:26 AM rue_mohr: but 3 things requires 2 bits beasue were using indexes 0-2
02:01 AM Ameisen: ceil(log2(2)) == 1
02:01 AM Ameisen: the one bit can represent the state 0 (first element) or 1 (second element)
02:01 AM Ameisen: a list of 1 things does not need any bits to represent which object you're pointing to, as you only have one object.
02:01 AM Ameisen: zero things also needs no bits to point to... nothing
02:02 AM Ameisen: ceil(log2(1)) == 0
02:02 AM rue_mohr: yay, a second oppinion!
02:02 AM Ameisen: not really an opinion
02:03 AM rue_mohr: it still hurts my head a little
02:03 AM rue_mohr: instinctivly, I take it a list of 1 items requires 1 bit
02:03 AM Ameisen: __uint1 works. Heck, __int1 works.
02:03 AM rue_mohr: rrly? thats halarious
02:03 AM Ameisen: Does what was expected - 1 byte, but can only have two vlaues.
02:03 AM rue_mohr: bit yea
02:03 AM rue_mohr: 0 and 1
02:04 AM Ameisen: 0-1, or -1 to 0
02:04 AM rue_mohr: or for signed, I suppose + or -0?
02:04 AM rue_mohr: -1 to 0?
02:04 AM rue_mohr: huh
02:04 AM Ameisen: that would be two's completely artihmetic.
02:04 AM Ameisen: complement*
02:05 AM Ameisen: float24 crashes. Still working on building with float16
02:05 AM rue_mohr: which processor?
02:20 AM antto: signed bool pls
02:20 AM rue_mohr: true, false, or nonexistant?
02:24 AM rue_mohr: wow, trying to understand code I wrote in 2006
02:56 AM Jartza: lol
02:56 AM Jartza: I found c64 basic code I wrote in 1984
02:57 AM Jartza: I have no fricking idea what it does, I guess I just have to transfer it to c64 or emulator and try it out
02:57 AM Jartza: it's just full of goto/gosub/goto/gosun
02:57 AM rue_mohr: heh
02:58 AM rue_mohr: I'v been pretty good since around then, the code is readable, my challange is understanding it
02:58 AM rue_mohr: /************************************
02:58 AM rue_mohr: 7.0 ok
02:58 AM rue_mohr: forward and reverse table navigation
02:58 AM rue_mohr: take an integer and translate it to details of a table line
02:58 AM rue_mohr: ************************************/
02:58 AM rue_mohr: void fromIndex(int * Limit, int LimitCount, int * Result, int i) {
02:58 AM rue_mohr: int j, k, n;
02:58 AM rue_mohr: for(j = LimitCount - 1; j >= 0; j--) {
02:58 AM rue_mohr: for (k = 0, n = 1; k < j; k++) n *= Limit[k];
02:58 AM rue_mohr: Result[j] = i / n;
02:58 AM rue_mohr: i -= (Result[j] * n);
02:58 AM rue_mohr:
02:58 AM rue_mohr: }
02:59 AM rue_mohr: }
02:59 AM rue_mohr: *blink*
02:59 AM rue_mohr: I think
03:00 AM rue_mohr: given variable length lists, it itterates thru the lists as if each digit is arbitrary base and returns the translation of a given index
03:01 AM rue_mohr: so , if the first digit was 0-3 and the second was 0-6 and the next was 0-2, what would the number 50 look like?
03:02 AM rue_mohr: numbers composed of arbitrary based digits...
03:02 AM rue_mohr: part of my challange right now is to 'normalize' them to 2^n
03:03 AM rue_mohr: and do something with all the invalid extra digits
03:04 AM rue_mohr: FSMinterlinkTable(FSM_t * this)
03:04 AM rue_mohr: and then there is *that* function to write
03:04 AM rue_mohr: I have a whole program that does *that*
03:04 AM rue_mohr: its not small
03:04 AM rue_mohr: show
03:05 AM rue_mohr: substate (fb)
03:05 AM rue_mohr: A
03:05 AM rue_mohr: B
03:05 AM rue_mohr: C
03:05 AM rue_mohr: Data (in)
03:05 AM rue_mohr: Set_0
03:05 AM rue_mohr: Clear_1
03:05 AM rue_mohr: --
03:05 AM rue_mohr: Set_0 , A
03:05 AM rue_mohr: Set_0 , B
03:05 AM rue_mohr: Set_0 , C
03:05 AM rue_mohr: Clear_1 , A
03:05 AM rue_mohr: Clear_1 , B
03:05 AM rue_mohr: Clear_1 , C
03:05 AM rue_mohr: its doing good so far tho
04:47 AM PsySc0rpi0n is now known as HelloShitty
04:53 AM polprog: ive got a resistor that is 680k on the schematic but when i measure it (synth powered off and unplugged) im reading 200k and the bargraph display is going back and forth slightly
04:53 AM polprog: weird
04:56 AM LeoNerd: Maybe the rest of the circuit in parallel with it is affecting it?
04:57 AM LeoNerd: nuxil: TDR?
04:57 AM LeoNerd: Oh, time-domain reflectometer? Yes but only unintentionally
05:43 AM * polprog slaps nuxil with a cathode ray tube
06:47 AM nuxil: LeoNerd, time domain reflectometer
06:47 AM nuxil: :D
06:55 AM nuxil: yes reset of the circuit can affect the mesurmen, (1/Z_unknonw) + (1/680k) = less than 680k
06:55 AM LeoNerd: Yup; am aware of that
07:04 AM antto: hm, is the SRAM always random when it's not cleared? i tried a long power-off (an hour maybe), and i still get non-zero bytes
07:08 AM nuxil: why do you care if the ram is cleared or not after a power-off ?
07:10 AM antto: it seems it's not cleared, but it doesn't seem to, sorta "discharge to zeros" like i suspected
07:10 AM antto: that's so nice
07:13 AM nuxil: try read the eeprom and you get a supprise :D
07:14 AM nuxil: full og garbage too. but my question remains. why do you care ?
07:14 AM nuxil: are you trying to read a aread of the memory without assgning a value to it 1st ?
07:15 AM nuxil: *area
07:18 AM antto: i'm approximating the behavior of an old sequencer from 1982, it uses battery-backed external SRAM for storage (cuz that's what they had back then) ... in our case we use an atmega with SPI eeprom
07:18 AM antto: i buffered the whole eeprom in SRAM for fastness and "better" writing
07:20 AM antto: the original device is famous for giving you "random" patterns if you forgot to keep the batteries alive for some time - i've approximated this effect artificially by having an actual randomizer algorithm
07:20 AM antto: but now i tried something else - i moved the actual data buffer into the .noinit section
07:20 AM antto: and it seems i get random contents, i expected less
07:22 AM nuxil: random is hard on avr
07:22 AM antto: what do you mean?
07:22 AM LeoNerd: Look for a library called "avr-entropy"
07:22 AM nuxil: i would no rely on sram or eeprom to generate the random numbers
07:22 AM antto: i got a prng already which is decent
07:23 AM LeoNerd: One of the tricks (which only works on newer AVRs) is to rely on clock desync between the fast WDT pre-warning interrupt and a fast 16bit timer
07:23 AM LeoNerd: If you sample the bottom few bits of TCNT1 at every WDT prewarning interrupt, the clock skew is noisy enough to use
07:23 AM antto: the prng i use is a 5-tap 16bit marsaglia algorithm
07:24 AM antto: i change the seed on boot
07:28 AM * Ameisen just uses xorshift* for a prng
07:30 AM antto: https://en.wikipedia.org/wiki/Multiply-with-carry <-
07:32 AM antto: simple algorithm, yet it has crazy long period
07:33 AM Ameisen: xorshift* is somewhat faster than MWC, and has better test results
07:33 AM antto: but i can just leave the SRAM uninitialized and get closer to the "original"
07:33 AM Ameisen: and has a period of 2^64 - 1
07:34 AM antto: oh wait
07:34 AM Ameisen: Marsaglia actually modifeid xorshift as well
07:34 AM antto: the thing i use here is actually a xorshift
07:34 AM antto: yeah, all i remember is it was by marsaglia and it has 5 taps
07:35 AM Ameisen: probably xorwow
07:35 AM Ameisen: they're all marsaglia though
07:35 AM Ameisen: everything is marsaglia
07:36 AM antto: yeah, he crazy
07:36 AM Ameisen: he dead
07:36 AM antto: oh?
07:36 AM Ameisen: since 2011
07:37 AM antto: :/
07:55 AM polprog: hm now that i think about it the noise slider might be broken the same way the square was
07:56 AM polprog: its identical, so ill just get two replacement sliders
08:11 AM Ameisen: I _really_ want to see if I can improve AVR's register allocation
08:11 AM Ameisen: I hate that it _has_ to allocate registers aligned to register pairs
08:12 AM Ameisen: a uint24? Reserves 4 registers.
08:12 AM Ameisen: and they are pair-aligned
08:31 AM nuxil: Ameisen, dosent uint24 reserve 3 registers ?
08:32 AM Ameisen: you'd think
08:32 AM Ameisen: that's not how the register allocator works
08:32 AM Ameisen: avr-gcc sets up pseudo-registers
08:32 AM Ameisen: preferring register-pairs
08:32 AM Ameisen: and it aligns up
08:32 AM Ameisen: after lowering it might only use three registers
08:32 AM Ameisen: but at register allocation time it uses four
08:33 AM Ameisen: it will also use four of passed as a function argument or a return value (in registers)
08:33 AM Ameisen: if*
08:39 AM Ameisen: hrmm
08:39 AM Ameisen: at minimum, I will have to create a new floating point mode type, I think (like... more-than-half-float-mode), create a new spec struct for 24-bit float...
08:39 AM Ameisen: and create the encode/decode functions for it
08:40 AM Ameisen: unsure if libgcc will autogenerate the helpers for arithmetic
08:55 AM nuxil: so whos gonna watch the eurovision today ? :p
08:55 AM Ameisen: woot
08:55 AM Ameisen: looks like I successfully added float16
08:55 AM Ameisen: :D
09:01 AM polprog: i wouldnt even know where to start adding a new type rofl
09:01 AM polprog: good job!
09:13 AM Ameisen: all of the gcc floating code in real.c... could be generic
09:13 AM Ameisen: like... their encode functions are almost duplicates of one another
09:13 AM Ameisen: except have hardcoded values for different exponent/significand bits
09:13 AM Ameisen: this could be trivially rewritten into one template
09:13 AM Ameisen: or even just a macro in C
09:14 AM Ameisen: this is really sloppy code
09:14 AM Ameisen: I'm guessing nobody has really touched it in a long time
09:17 AM Ameisen: half: SET_REAL_EXP(r, -14);
09:17 AM Ameisen: single: SET_REAL_EXP (r, -126);
09:17 AM Ameisen: this can be written has:
09:17 AM Ameisen: SET_REAL_EXP(r, ((1ul << exponent_bits) - 2));
09:18 AM antto: when i need more than 16bit - i use 32bit
09:21 AM nuxil: yea that makes sense
09:21 AM Ameisen: SET_REAL_EXP(r, ~((1ul << exponent) - 1) | 0x2ul);
09:21 AM Ameisen: rather
09:21 AM Ameisen: sorry
09:21 AM Ameisen: they were doing negative->unsigned conversion
09:21 AM Ameisen: so a single with 8 exponent bits was expanding that to 0b11111111111111111111111110000010
09:21 AM Ameisen: which is all ones, the lower 7 bits (8 - 1) being 0, but the second bit being 1
09:22 AM Ameisen: half with 5 exponent bits was expanding to 0b11111111111111111111111111110010
09:23 AM Ameisen: evidently, I can disable signed zeros in GCC.
09:23 AM Ameisen: interesting. Might speed up float calculations.
09:23 AM Ameisen: presuming it causes it to operate as two's complement instead of requiring separate sign logic
09:23 AM Ameisen: the format structures have 'has_signed_zero'
09:23 AM Ameisen: they also have 'has_denorm', etc
09:23 AM Ameisen: majority of that is meaningless for software
09:24 AM antto: mmm denormals >)
09:24 AM Ameisen: not sure if the software version is slower for denormals
09:24 AM Ameisen: denormals are fun though
09:24 AM Ameisen: since a single value can have mlutiple representations
09:24 AM Ameisen: only one is canonical
09:24 AM Ameisen: the others are all denormal
09:24 AM Ameisen: and waaaay slower in hardware
09:24 AM Ameisen: software should be the same speed though?
09:25 AM antto: no idea, but on the computer, when you get a denormal somewhere - boom, cpu becomes an oven
09:47 AM Ameisen: yes
09:47 AM Ameisen: FPU representation means that one value can have multiple representations
09:47 AM Ameisen: think 10 * 1 or 1 * 10 (but more complex and exponential)
09:48 AM Ameisen: only one is canonical (IIRC, the one that has the upper-most different bit as zero)
09:48 AM Ameisen: the others are not optimized for in the FPU and are denormalized
09:48 AM Ameisen: so the FPU has to do a ton of work to make it work
09:48 AM Ameisen: or throws an FPU exception if it's enabled
10:11 AM Ameisen: https://pastebin.com/L0q3nkn6
10:11 AM Ameisen: that seems reasonablel
10:11 AM Ameisen: 10000 is totally not a made-up cost
10:20 AM Ameisen: odd
10:20 AM Ameisen: they calculate variable move costs based on size. If size == 1, cost is 1. If it's > 1, it's generally 2 * size - 1
10:20 AM Ameisen: however, SFmode (which is a float, 4-byte) uses '1'
10:20 AM Ameisen: that doesn't seem right
10:20 AM Ameisen: cost should be the same as a 4-byte integer
10:44 AM Ameisen: NM. Misread what was going on. That was the cost for calling NEG, which makes sense that any floating-point type would be 1 cycle
10:44 AM Ameisen: since you only have to set the sign bit
11:03 AM Ameisen: "volatile" forces reading low byte first, even if less efficient, for correct operation with 16-bit I/O registers.
11:03 AM Ameisen: ""
11:03 AM Ameisen: why?
11:03 AM Ameisen: Presuming someone here knows the AVR ISA deeply enough to explain that
11:14 AM polprog: sometimes reading the high bit triggers an action iirc
11:15 AM polprog: for example
11:15 AM polprog: https://www.mouser.com/datasheet/2/268/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_dat-1315266.pdf
11:15 AM polprog: page 77, on the bottom
11:16 AM antto: SFRs are tricky
11:19 AM polprog: what does SFR stand for?
11:19 AM antto: special F??? register
11:20 AM polprog: i see
11:20 AM antto: afaik that's pretty much all of the lower bytes in RAM, where the PORTs and other peripherals go
11:20 AM antto: they got tricky things like, some bits are read only, others are write only, etc..
11:20 AM polprog: yeah
11:21 AM polprog: my favourite part is this: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_assign_chain
11:21 AM antto: sometimes, to clear a bit, you write it as 0b1
11:21 AM polprog: trappy trap
11:23 AM antto: Ameisen what's that thing about __flash that you were talking about?
11:27 AM Ameisen: seems like then that a different type modifier is needed
11:27 AM Ameisen: instead of volatile
11:27 AM Ameisen: right now it rewrites _all_ 16-bit volatiles to be reversed
11:28 AM Ameisen: maybe something like ioport
11:28 AM Ameisen: antto - g++ does not have the C extensions for embedded architecures implemented
11:28 AM Ameisen: which includes things like __flash and __memx
11:28 AM Ameisen: gcc does
11:32 AM antto: the only thing i find about it is that it comes from IAR and is equivalent to __attribute__((__progmem__))
11:33 AM antto: isn't that sorta equivalent to section (.text) then?
01:17 PM Ameisen: IAR functions differently than GCC
01:18 PM Ameisen: https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html
02:00 PM polprog: https://encyclotronic.com/uploads/monthly_2016_12/585c0624182e0_Roland_SH_101_synthesizer_advert_1982(1).jpg.161f44de9cea103cf8e67d94cce00633.jpg
02:19 PM Ameisen: I added some code to try to derive the address of those volatile accesses, and detect if it's possible it's an 16-IO read, and if the address is known, check if it's one of the 16-bit IO registers
02:19 PM Ameisen: so now not all 16-bit volatile accessess will be reversed
02:33 PM Emil: polprog: I'm thinking about learning ED
02:33 PM Emil: and replacing nano with ED
02:33 PM Emil: :D
02:34 PM skz81: <polprog> what does SFR stand for? >> Société Française du Radiotéléphone :p
02:37 PM skz81: <Emil> polprog: I'm thinking about learning ED >> I agree, Elite Dangerous is a very great game !!
02:37 PM polprog: special fuckup register
02:38 PM Emil: I hate people who do chain assignment
02:38 PM Emil: I looks horrible
02:38 PM skz81: Semmingly Funny Requests
02:39 PM skz81: <Emil> I looks horrible >> You look horrible...
02:39 PM skz81: Emil, you meaning multiple '=' on the same "line" ?
02:40 PM Emil: skz81: yeah
02:41 PM Emil: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_assign_chain
02:41 PM Emil: I look absolutely great
02:41 PM Emil: if you cut my stomatch out of the picture
02:41 PM Emil: I trimmed my beard and like 20 years just vanished :D
02:42 PM skz81: << assigned to DDRD, then DDRD is read back, and the value is assigned to DDRB. The compiler stands no chance to optimize the readback away, as an IO port register is declared "volatile". >>
02:43 PM skz81: interesting note !
02:43 PM Emil: read the one below
02:43 PM Emil: about m1281
02:43 PM skz81: I very reraly use this, anyway... but good to keep in mind
02:44 PM skz81: lol !!
03:21 PM Ameisen: I think that there's only... 3 16-bit registers where the access order matters, on AVR6
03:21 PM Ameisen: I don't think the ADC and EEAR registers care?
03:22 PM Ameisen: that isolates the range of addresses that need to be reversed to [0x46, 0x50)
03:24 PM polprog: i dont know which is which
03:24 PM polprog: which is avr6 and which isnt
03:25 PM polprog: would be easier to just mark off the io register range (all sfrs) and apply that only to that range
03:25 PM polprog: or whatever you are doing
03:25 PM polprog: what exactly do you wanna change?
03:35 PM antto: Ameisen i think my atmega2561 is avr6
03:37 PM Ameisen: polprog - have to go over every AVR set to get those registers.
03:38 PM Ameisen: but really, it's a very tiny range that applies
03:38 PM Ameisen: like, 3 registers
03:38 PM Ameisen: usually
03:38 PM polprog: yeah, but can you simplify that
03:38 PM polprog: and just apply it to the first 255 or so bytes
03:38 PM polprog: i dont remember what change are you making
03:39 PM antto: 0 to RAMSTART
03:39 PM polprog: yeah
03:39 PM Ameisen: 0x20 to RAMSTART
03:39 PM Ameisen: no reason to cover GPRs
03:40 PM polprog: yeah, but do you do atomic reads from gprs :p
03:41 PM Ameisen: if they're marked as volatile.
03:42 PM polprog: i think you cant even access those as memory addresses
04:30 PM polprog: heres what happens when you use blocking io
04:30 PM polprog: https://v.redd.it/2do5wa0txax01
05:25 PM nuxil: ?
05:26 PM nuxil: link is not working. well its working if its not suppose to work :p
05:28 PM nuxil: https://i.redditmedia.com/b59lzZLo5Jc1nUqvbOBrBzwC5OQqrTRS3SdsUI9sf2k.jpg?s=3ea08f004e59e922fc3699accf300875 :D
05:29 PM Ameisen: yeah, naive asynchronous code tends to do that
05:30 PM nuxil: :)
05:32 PM Ameisen: my cell simulator is way less blocking
05:32 PM Ameisen: but it was designed to be as parallelized as I could get it
05:33 PM nuxil: so Ameisen with floats and this 754 stuff you got the format [sign] [exponent] [significant], but since you use a bias with the exponent you will know if its a negative or not. so is the 1st [sign] bit really needed?
05:35 PM Ameisen: No.
05:35 PM Ameisen: It's there because IEEE floats aren't two's complement
05:35 PM Ameisen: you could represent the float as a two's complement value instead
05:35 PM Ameisen: it would likely be faster
05:35 PM Ameisen: for software-emulation at least
05:36 PM Ameisen: instead of having to hadnle a sign bit separately, your operations would work re: addition and subtraction as they normally would
05:36 PM Ameisen: there's a ton of ways you can design floats.
05:36 PM Ameisen: I'm going to write a very simple emulator just for benchmarking simple routines
05:36 PM Ameisen: then I can benchmark some stuff
05:37 PM Ameisen: I will try to implement a simplified floating-point format in C++ wrapped around a class
05:37 PM Ameisen: see how it performs against the software-emulated IEEE floats
05:37 PM nuxil: alright
05:37 PM Ameisen: might also try a few not-quite-floating formats
05:37 PM Ameisen: including one based aorund multiplication instead of exponentiation
05:37 PM Ameisen: and one that is literally just a 'varying-point type'
05:37 PM Ameisen: where N bits are reserved to specify where the decimal is
05:38 PM Ameisen: That one I think would work well with fixed-precision math where you might sometimes get unusual sizes as an intermediate value
05:38 PM Ameisen: obviously exponent-based ones can handle much, much larger ranges though
05:39 PM Ameisen: Another idea could be a type where it is just 'shift : value'
05:40 PM Ameisen: shift would be considered to be a signed value. Value is shifted by that much left or right. Shifting it right pushes those bits into decimal. Left multiplies it by two (obviously)
05:40 PM Ameisen: would be faster than the normal exponent ones
05:40 PM Ameisen: though would lose precision more rapidly
05:40 PM Ameisen: well, shifting isn't quite that simple obviously since you have to do an arithmetic shift unless it's an unsigned type
05:41 PM Ameisen: there's lots of ways to implement such things
05:42 PM Ameisen: Honestly, IEEE floats are probably the absolute _worst_ solution, particularly for emulation
05:42 PM Ameisen: unless you really _need_ it to be IEEE-compliant
05:42 PM nuxil: you really dont need it to be on avr .. or ?
05:43 PM Ameisen: hrmm?
05:43 PM Ameisen: well, most of these'd work on ARM as well
05:43 PM nuxil: <Ameisen> unless you really _need_ it to be IEEE-compliant
05:43 PM Ameisen: tohugh if you have an ARM chip with an FPU, a float makes more sense
05:43 PM nuxil: i mean. it no reason for it to be that
05:43 PM Ameisen: the main reason is that all the libraries use IEEE floats, and the compilers implement IEEE
05:43 PM Ameisen: you can obviously implement your own
05:43 PM Ameisen: but what you're given is a software-emulated IEEE float
05:44 PM nuxil: ofc.
05:44 PM Ameisen: once you start implementing your own, you lose some of the niceties of built-in types
05:44 PM Ameisen: mainly that they're considered primitive POD
05:44 PM Ameisen: your implementations generally _aren't_
05:46 PM nuxil: POD ? Plain Old Data?
05:50 PM nuxil: nm
06:03 PM Ameisen: yeah
06:31 PM polprog: goodnight
09:53 PM rue_mohr: ./a.
10:55 PM * nuxil yawns
10:56 PM antto: my cat woke me up
10:56 PM nuxil: im makeing coffee
10:56 PM antto: i think she was hunting a roach
10:56 PM nuxil: :D
10:56 PM Ameisen: running into build errors with libgcc when dicking with FPU types
10:56 PM Ameisen: strange errors
10:56 PM Ameisen: it's like GCC itself is aware of the types but isn't passing the type info down
11:02 PM Ameisen: libgcc/fp-bit.c:320:3: In function '__pack_f': internal compiler error: Segmentation fault: dst.bits.fraction = fraction;
11:02 PM Ameisen: I presume that 'dst' is a reference, and somehow it's invalid.
11:13 PM nuxil: im making a new layout for my 4x4 matrix keypad, i placed the keypad in my scanner so i got a nice template :D
11:14 PM Ameisen: you should use my __uint1 type!
11:14 PM Ameisen: or my __int1 type!
11:14 PM Ameisen: ;)
11:14 PM nuxil: normaly one would use gimp/ps etc to do this. but not me.. im making it in my 3d app :p
11:14 PM Ameisen: though 4x4?
11:14 PM nuxil: wip so far https://gyazo.com/da6e489f996db1bc0a857cb37d210b7d
11:14 PM Ameisen: you should use my __uint4 type!
11:15 PM Ameisen: I just decided to emit integer types of all the powers of two up to 128
11:15 PM Ameisen: because why not.
11:15 PM nuxil: will print it out and laminate onto it.
11:17 PM Ameisen: well, pow2 up to 8
11:17 PM Ameisen: then incrementing by 8
11:17 PM Ameisen: 1 2 4 8 16 24 32 40 48 56 64...
11:18 PM antto: uint12_t could be useful
11:19 PM Ameisen: when
11:19 PM antto: UBRR, some ADCs, BSEL are 12bit integers
11:19 PM antto: but they are in SFRs
11:20 PM Ameisen: they're 12bit integers but are represented by 16-bits
11:20 PM antto: yeah, but you could maybe use some union struct thing
11:21 PM antto: { uint12_t BSEL; int4_t BSCALE; } where bscale is shifted above bsel (forgot how that's done)
11:22 PM Ameisen: packing won't do what you want.
11:22 PM Ameisen: you need to use bitfields for that
11:22 PM antto: yes, bitfields
11:22 PM Ameisen: uint16_t BSEL : 12; uint16_t BSCALE : 4;
11:23 PM antto: uhm, but how would you use this in the code then?
11:23 PM Ameisen: for other things
11:23 PM antto: bscale has to be a signed integer with a valid value between -7 and +7
11:23 PM Ameisen: if you want quick-and-easy value constraints in a function
11:25 PM Ameisen: struct { uint16_t BSEL : 12; int16_t BSCALE : 4; };
11:26 PM antto: does that prevent you from assigning 63 to bscale and messing up bits from bsel?