code logs -> 2017 -> Sun, 27 Aug 2017< code.20170826.log - code.20170828.log >
--- Log opened Sun Aug 27 00:00:19 2017
01:18 Kindamoody is now known as Kindamoody[zZz]
01:44 Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds]
01:49 Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code
01:49 mode/#code [+o Alek] by ChanServ
02:11 RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Ping timeout: 121 seconds]
02:16 RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code
02:53 RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Ping timeout: 121 seconds]
03:49 Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has quit [Connection closed]
03:54 Jessikat [Jessikat@Nightstar-bcsf5u.dab.02.net] has joined #code
04:23 Degi [Degi@Nightstar-0khobc.dyn.telefonica.de] has quit [Connection closed]
05:45 Derakon is now known as Derakon[AFK]
06:15 Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed]
06:15 Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code
06:15 mode/#code [+qo Vornicus Vornicus] by ChanServ
06:55 celticminstrel [celticminst@Nightstar-1vj9md.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
08:04 Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed]
08:38 Jessikat` [Jessikat@Nightstar-s27guf.dab.02.net] has joined #code
08:41 Jessikat [Jessikat@Nightstar-bcsf5u.dab.02.net] has quit [Ping timeout: 121 seconds]
09:09 Kindamoody[zZz] is now known as Kindamoody
10:04 Jessikat` [Jessikat@Nightstar-s27guf.dab.02.net] has quit [[NS] Quit: Bye]
10:31 Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [[NS] Quit: Rebooting...]
10:51 Kindamoody|autojoin [Kindamoody@Nightstar-rkmbuo.mobileonline.telia.com] has joined #code
10:51 mode/#code [+o Kindamoody|autojoin] by ChanServ
10:52 Kindamoody|autojoin is now known as Kindamoody
11:37 Jessikat [Jessikat@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code
12:06 Kindamoody [Kindamoody@Nightstar-rkmbuo.mobileonline.telia.com] has quit [Client exited]
12:07 Kindamoody|autojoin [Kindamoody@Nightstar-rkmbuo.mobileonline.telia.com] has joined #code
12:07 mode/#code [+o Kindamoody|autojoin] by ChanServ
12:07 Kindamoody|autojoin is now known as Kindamoody
12:56 Degi [Degi@Nightstar-0khobc.dyn.telefonica.de] has joined #code
13:01 Kindamoody is now known as Kindamoody|out
13:15 RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code
--- Log closed Sun Aug 27 14:15:06 2017
--- Log opened Sun Aug 27 14:35:29 2017
14:35 TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code
14:35 Irssi: #code: Total of 34 nicks [24 ops, 0 halfops, 0 voices, 10 normal]
14:35 mode/#code [+o TheWatcher] by ChanServ
14:36 Orthia [quassel@Nightstar-ksqup0.co.uk] has joined #code
14:36 mode/#code [+o Orthia] by ChanServ
14:36 Irssi: Join to #code was synced in 56 secs
19:35 Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [Ping timeout: 121 seconds]
19:39 Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code
19:39 mode/#code [+o Alek] by ChanServ
19:50 Degi_ [Degi@Nightstar-fai.3fq.165.46.IP] has joined #code
19:53 Degi [Degi@Nightstar-0khobc.dyn.telefonica.de] has quit [Ping timeout: 121 seconds]
19:54
< RchrdB>
“It's tempting to read the input a couple of times each pass through the 500 msec loop and look for a stable signal. That'll reject much or maybe all of the EMI. But some environments are notoriously noisy. Many years ago I put a system using several Z80s and a PDP-11 in a steel mill. A motor the size of a house drawing thousands of amps drove the production line. It reversed direction every few seconds. The noise generated by that changeove
19:54
< RchrdB>
r coupled everywhere, and destroyed everything electronic unless carefully protected. We optocoupled all cabling simply to keep the smoke inside the ICs, where it belongs. All digital inputs still looked like hash and needed an astonishing amount of debounce and signal conditioning.”
19:55
< RchrdB>
reading http://www.ganssle.com/debouncing-pt2.htm
20:00
<@Tamber>
It's amazing just how brutal big inductive loads like that can be.
20:02
< RchrdB>
I bet that factory has a giant sign on the gate saying STRICTLY NO PACEMAKERS ALLOWED
20:08 Degi [Degi@Nightstar-0khobc.dyn.telefonica.de] has joined #code
20:08 Degi_ [Degi@Nightstar-fai.3fq.165.46.IP] has quit [Ping timeout: 121 seconds]
20:55 Kindamoody|out is now known as Kindamoody
20:58
<&McMartin>
It's kind of weird to me to see "Several Z80s and a PDP-11"
21:00
<&McMartin>
It's not actually "Several Athlon-64s and a SPARCstation", but it feels like it because the Z80 lasted so long
21:04
< RchrdB>
They still make backwards compatible Z80 derivatives.
21:05
< RchrdB>
I guess you usually hear about those little Atmel microprocessors in hobby kit instead these days, because Arduino?
21:05
<&McMartin>
Pretty much, and honestly ARM chips are getting price-competitive at the low end.
21:14
< RchrdB>
That said, for these kinds of industrial process control applications, I guess you'd be looking at a 50p microcontroller versus a 66p microcontroller, but either way that's going to be bolted to like £20 or more's worth of optoisolators, MOSFETs and relays to get signals in and out safely, and on the other end of that will be equipment worth many multiples of £10k
21:15
< RchrdB>
so no point quibbling over a little price difference for the µc :)
21:16
<@Tamber>
66p microcontroller, in a £850 PLC, surrounded by £2500 worth of fuses, contactors, relays, etc.? at the end of the day, it's a bit of a wash. :D
21:16
<@Tamber>
Process control stuff gets pricey quick.
21:16
<&McMartin>
When the thing being controlled isn't micro, you stop worrying about a lot of things
21:17
<@Tamber>
Yeah, "how much does the µC cost" is a non-issue when it's running £35M of plant.
21:18
< RchrdB>
I wonder if going all ARM saves you a significant amount of money on software dev costs because, for the bits where the ISA matters, there are more people who know ARM than any other ISA except x86?
21:19
< RchrdB>
that and you can think about using nice high-quality compiler backends like gcc and llvm, instead of some random microcontroller vendor's "we swear it (approximately) implements (some of) the c89 spec, honest guv!" shitty C compiler.
21:19
<&McMartin>
At this point, I'm not even willing to take "except x86" for granted.
21:20
< RchrdB>
I wouldn't want to bet either way on that one. How many people know ARM because it lets them do stuff on their phones vs how many people know x86 because it lets them do stuff on their servers and workstations.
21:20
<@Tamber>
RB: "approximately implements some of the c89 spec, honest. Oh, and you need to sign this NDA. Oh, and you need to pay £EXTORTIONATE for the privilege. And that's per-seat, btw."~?
21:20
< RchrdB>
Tamber, ow, ow and ow.
21:20
<&McMartin>
That's ARM~
21:20
<&McMartin>
At least if the ARM device is an iPhone.
21:20
<&McMartin>
"Also keep paying dues or your software will self-destruct in-place"
21:21
<&McMartin>
I will, extremely grudgingly, admit that this did produce the effect where they were able to shift the entire architecture underneath their users without most of them noticing.
21:21
< RchrdB>
XCode and iOS dev licenses are pretty cheap.
21:21
< RchrdB>
Comparative to, like, employing a software developer pretty much anywhere on the planet.
21:22
<@Tamber>
On the note of the phones thing, how many of the people who "do things on phones" actually get to the point where you need to know "ARM" (vs. "x86", etc) as opposed to "It's pretty much just [Java,ObjC], but..."?
21:22
<&McMartin>
The ability to read asm out of a crash dump is as helpful on phones as it is anywhere else.
21:23
< RchrdB>
Tamber, well, that's the other reason why I wouldn't want to take that bet.
21:23
<&McMartin>
It's true that you generally don't hit the level while writing code often.
21:23
< RchrdB>
the same question exists about the world of PCs and servers too.
21:23
<@Tamber>
Ah, I suppose so.
21:23
<&McMartin>
... so, really, the people who will know the code the best are ROM hackers.
21:23
<&McMartin>
Guess we'd better put PPC in the list~
21:23
< RchrdB>
OTOH I would expect a lot more people to be at the level of ISA when working on the really small stuff that's much smaller than phones? but there aren't all that many of those people compared to the number of people writing phone or server apps.
21:24
< RchrdB>
McMartin, everyone I know of who knows PPC also counts as knowing x86 intimately too though because they're all developers on Dolphin ;)
21:24
< RchrdB>
anyway, question
21:24
< RchrdB>
«<McMartin> I will, extremely grudgingly, admit that this did produce the effect where they were able to shift the entire architecture underneath their users without most of them noticing.» ← do you mean the switch from arm32 to aarch64?
21:25
<&McMartin>
Yes, because they have far less to do with one another than IA32 does to x86_64
21:25
< RchrdB>
oh interesting i did not know that
21:26
<&McMartin>
Though admittedly for my use of it (reading crash dumps in a debugger), the only real issue is the ABI changing a bit
21:26
< RchrdB>
Does aarch64 get rid of many interesting quirks that were once useful but now just a mild drag?
21:26
<&McMartin>
Yes; the barrel-shift-in-every-instruction and the condition-execution flags are both gone :(
21:26
<&McMartin>
All the fun SHENZHEN I/O stuff :(
21:26
< RchrdB>
stuff like Thumb and Thumb2 being separate things, or stuff like every opcode supporting being conditional rather than just a handful of MOV opcodes supporting conditionality
21:26
<@Tamber>
McM: All the stuff that made Magic happen~?
21:27
<@Tamber>
(Well. Magic™.
21:27
<@Tamber>
)
21:27
<&McMartin>
The latter, but if we're going to get right down to it, I'm considering Thumb, Thumb2, and Arm32 to be three ISAs.
21:27
<&McMartin>
And I'm singingly loudly and pretending as hard as I can that Jazelle never existed.
21:28
<&McMartin>
In my defense, ARM Holdings appears to be doing the same~
21:28
< RchrdB>
<the Computer is our obviously our friend, no need to question this at all voice> What never existed?
21:28
< RchrdB>
so
21:28
<@Tamber>
la
21:29
< RchrdB>
Does aarch64 have better instruction density since they no longer burn quite so many bits for conditions and stuff on every instruction?
21:29
<&McMartin>
I have not looked deeply into encodings.
21:29
<&McMartin>
I suspect instruction density is worse, though. >_>
21:30
<&McMartin>
Unless it's doing the Thumb2 thing across the board, which it might!
21:30
<&McMartin>
If it stays with "each instruction is one machine word wide", though, like arm32, and mips, then that doubles the size of every instruction.
21:31
<&McMartin>
(Thumb was halfword for every instruction, and thumb2 was variable-width.)
21:31
< RchrdB>
This random document I just found from ARM implies that every aarch64 instruction is at most 32 bits wide
21:31
< RchrdB>
it also seems to imply that every aarch64 instruction is at least 32 bits wide but I'm not certain I read that bit right
21:32
<&McMartin>
"Instructions are still 32 bits long and mostly the same as A32 (with LDM/STM instructions and most conditional execution dropped)."
21:32
< RchrdB>
ah yeah I think that's actually correct, wikipedia corroborates it
21:32
<&McMartin>
I suspect instruction density is similar or slightly worse, but has better cache coherency now that branch predictors work
21:32
<&McMartin>
And the extra instruction space is going to register indices because there are now twice as many.
21:33
<@Tamber>
("...which is all very impressive, considering computers are just rocks with lightning trapped in them, that we've tricked into thinking!")
21:33
< RchrdB>
This doc http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/ch05s01.html implies that stuff might be slightly better sometimes
21:33
< RchrdB>
because you get more bits for immediates, so you wouldn't need to reach for a constant pool quite so often
21:34
<&McMartin>
Yeah
21:34
<&McMartin>
Raw instruction density has never been a major ARM concern, I don't think.
21:36
< RchrdB>
One presumes that they investigated the performance gain that they got from Thumb2 having more compact code and made a rational engineering choice that it would be better overall to splurge more on icache instead of putting up with the difficulties of a variable length encoding.
21:39
<&McMartin>
I would be completely unsurprised to learn that this is the case.
21:39
<&McMartin>
All the documentation around Thumb2 had a certain air of "you should only be using this if storage space is very, very dear"
21:40
< RchrdB>
I didn't know that.
21:40
<&McMartin>
It's a pity because it's a lovely feat of engineering
21:40
<&McMartin>
But I guess if you wanted to make complicated stuff go fast, you'd literally be Intel >_>
21:41
< RchrdB>
I bet when you get down to it, you can probably more-cheaply construct a probability model for ARM instructions and throw it at an entropy coder to get a compact representation for putting on a wire, assuming gzip isn't good enough.
21:41
<&McMartin>
Also huh, the removal of LDM STM explains some ABI weirdness, I guess, but I don't yet actually know the details.
21:41
<&McMartin>
(Thumb1, I think, was designed for the Game Boy Advance-style usecase of "This device can only afford a 16-bit data bus")
21:42
< RchrdB>
That and "in 2017, my iPhone app is about 70% retina-resolution raster images, 5% ARM code, 25% misc, so fuck wasting time optimising the ARM code bit of that"
21:42
<&McMartin>
Yep
21:42
<&McMartin>
Arm instruction encodings are kind of nightmarish, though. A lot of the argument bits tend to be noncontiguous within the instruction, which is a nasty shock coming from the 8-bits or even the 16-bits, I tell you what
21:43
< RchrdB>
the last-but-one phone app I worked on was about two-thirds database by volume
21:43
<&McMartin>
Checks out
21:43
<&McMartin>
And yeah. This stuff Just Isn't A Problem unless you have a tiny mask ROM feeding a microcontroller.
21:43
< RchrdB>
as in we shipped a sqlite DB and a load of JPEGs in it, because the app is basically a catalogue and it needed to work offline
21:43
<&McMartin>
That device better be the size a postage stamp. tops.
21:44
< RchrdB>
so almost all the download size is that DB
21:44
<&McMartin>
I love how iOS and Android both ship with sqlite and app developers can never get away with actually using it because it's unstable, but it's one public-domain C fail anyway so fuck it, throw it in the raw source
21:44
< RchrdB>
I had kind of wondered about that myself.
21:44
<&McMartin>
*file anyway
21:45
<&McMartin>
sqlite is surprisingly short on fail as long as you don't push it too hard.
21:45
< RchrdB>
Also sometimes people go "ehhh but I don't want rando losers pulling the sqlite DB out the APK file and just reading it" so now you get... sqlcipher! https://www.zetetic.net/sqlcipher/
21:45
< RchrdB>
Mostly yeah. I can tell you firsthand that the react-native bindings for it kind of suck.
21:46
< RchrdB>
and one of my colleagues was very disappointed when I had to explain what it meant that sqlite column types are actually referred to as the fields having a type "affinity" rather than the fields having a type
21:46
<&[R]>
<McMartin> sqlite is surprisingly short on fail as long as you don't push it too hard. <-- such as expecting it to enforce types!
21:47
< RchrdB>
[R], btdtgtts
21:47
<&McMartin>
It's very upfront about its attitude towards types.
21:47
<&[R]>
btdtgtts?
21:47
<&McMartin>
Been There Done That Got The T-Shirt
21:47
< RchrdB>
Been there, done that, got the t-shirt. :)
21:47
< RchrdB>
21:48
<&McMartin>
It is, in fact, sufficiently upfront about its attitude towards types that I would consider expecting that to be not so much "pushing it too hard" but more like "expecting my MongoDB API calls to work"
21:48
< RchrdB>
well yes but no but ehhhhh
21:48
<&McMartin>
(Or perhaps less overgenerously, "expecting a NoSQL database to not involve SQL")
21:48
<&[R]>
Is there any other SQL DB that does that?
21:49
< RchrdB>
I mean it managed to catch out one of my colleagues, who is not a stupid man, but possibly didn't have experience with sqlite itself so much as expect it to work like other sql dbs that he's worked with in the past
21:49
<@Tamber>
(*eyes RB* "Yes, no, maybe, I don't know, can you repeat the question?")
21:49
< RchrdB>
[R], sqlite's types thing? as far as I know, no other SQL db does it.
21:49
< RchrdB>
Tamber, sorry, which question?
21:50
<&McMartin>
"SQLite uses dynamic typing" is the second and third FAQ.
21:50
<&McMartin>
I guess I'm less generous on this because I knew going in I'd need to read all the docs before I wrote a single line of code, as a novice in the field.
21:50
<@Tamber>
Oh, I was aiming to make a joking reference at your "yes but no"; guess it's not quite as well-known as I thought.
21:50
< RchrdB>
Tamber, oh heehee ♥
21:50
<&[R]>
I don't recall that coming up when looking over the docs (mind you I was using the python bindings at the time)
21:51
< RchrdB>
anyway this did very briefly make me wonder if anyone wrote bindings for firebird buuuuut I never used that before so who even knows what kind of fun problems…
21:53
<&McMartin>
RchrdB: It's sqlite.org's FAQ page, which I admit is more likely to be checked at all if one is standing up one's first DB system instead of one's fiftieth, and also if one is working in C.
21:53
<&McMartin>
But now, I must away for adventures.
21:53
< RchrdB>
well sure I knew this but
21:53
< RchrdB>
not everybody reads all the documentation when there's a deadline like next week or something
21:55
< RchrdB>
McMartin, have fun on your adventures, be nice to any and all prince(sse)(s) along the way ♥
22:59 Derakon[AFK] is now known as Derakon
--- Log closed Mon Aug 28 00:00:22 2017
code logs -> 2017 -> Sun, 27 Aug 2017< code.20170826.log - code.20170828.log >

[ Latest log file ]