| sorear | do you expect to get more units in the field than there are currently, say, m68k or ia64 systems? | 00:00 |
|---|---|---|
| programmerjake[m | depends on how many m68k or ia64 systems there are, we're expecting at least around 100k units otherwise we wouldn't make enough to recoup costs | 00:03 |
| programmerjake[m | hoping for >500k | 00:03 |
| lxo | let's not aim for any less than total world domination ;-) | 00:04 |
| programmerjake[m | yeah, but I doubt that will happen right away... | 00:05 |
| rsc | >500k systems without mainstream OS support sounds IMHO ambitious if there aren't large businesses using them for their own purposes. | 00:05 |
| programmerjake[m | world domination takes time :) | 00:05 |
| programmerjake[m | hence why we're trying to get mainstream powerpc64le os support | 00:06 |
| sorear | given what I've seen in the riscv world anything more than 1k for a SBC seems optimistic, but I hope you're right | 00:07 |
| programmerjake[m | iirc we already have some customers lined up for at least 50k units | 00:07 |
| jn__ | if the Raptor TalosBook with Libre-SoC comes out in five years, i'll buy it :) | 00:08 |
| programmerjake[m | :D | 00:09 |
| programmerjake[m | sorear: remember, SBCs are only one of many applications for Libre-SOC | 00:10 |
| segher | lxo: no, sorry | 00:35 |
| segher | i do not know if it will make sense at all eventually | 00:36 |
| segher | we do *not* want to fragment what modes we have, etc. | 00:36 |
| segher | we already have way too much exponential complexity; i am trying to get rid of that, not add more | 00:36 |
| segher | (and you *need* literals, in the debug info) | 00:37 |
| lxo | segher, err, it doesn't look like I was clear on what the patch does | 00:41 |
| lxo | - for (int i = info->first_fp_reg_save; i < 64; i++) | 00:42 |
| lxo | + for (int i = info->first_fp_reg_save; i < LAST_FPR_REGNO + 1; i++) | 00:42 |
| lxo | is this not a desirable change? we already use this for altivec regs, why not gpr, fpr? | 00:45 |
| segher | i renumbered the registers not too long ago so that the numbering makes sense | 00:46 |
| segher | 0..31 GPRs, 32..63 FPRs, 64..95 VRs, 100..107 CR fields | 00:47 |
| lxo | in my book, using symbolic, mnemonic names for constants is superior software engineering than literals | 00:47 |
| programmerjake[m | +1 for symbolic names | 00:48 |
| segher | you see the raw numbers in debug dumps | 00:48 |
| lxo | yeah, we do, so what? | 00:49 |
| segher | and it is important for performance to have those first three ordered like that | 00:49 |
| programmerjake[m | debug dumpers can be improved to show symbolic names... | 00:49 |
| lxo | it's not like I'm trying to hide the numbers, I'm just trying to make them meaningful | 00:49 |
| segher | lxo: i look at those dumps all day every day, and there are more people doing that | 00:49 |
| segher | and GCC *does* print the symbolic names as well | 00:49 |
| segher | GPR0 is printed as 0 | 00:50 |
| lxo | dude | 00:50 |
| lxo | please listen | 00:50 |
| segher | FPR0 is printed as 0 | 00:50 |
| lxo | I'm not talking about outputs | 00:50 |
| lxo | I'm talking about the code in gcc/config/rs6000/ | 00:50 |
| segher | so we need the raw numbers to be readable | 00:50 |
| lxo | when you see a 29 or a 62 in there, that's not meaningful | 00:51 |
| segher | they also cannot change easily, because we have to translate them (in a few ways!) for the debug info | 00:51 |
| sorear | what if ... octal or hex | 00:51 |
| lxo | when you see a 32 or 64, is that a FPR or VEC register, or is it one past the end of GPR or FPR? | 00:51 |
| segher | sorear: they are always decimal | 00:51 |
| segher | 32 is an FPR | 00:51 |
| sorear | that seems like the problem. | 00:51 |
| segher | 64 is VR | 00:51 |
| segher | it cannot be one past | 00:51 |
| lxo | segher, yeah, until they're used as the boundary to end the loop over GPRs and FPRs, respectively | 00:52 |
| segher | we never have numbers that do not denote a register | 00:52 |
| lxo | see above | 00:52 |
| segher | yes, that uses +1 for a reason | 00:52 |
| lxo | I put the +1 there | 00:52 |
| lxo | that's part of the patch | 00:53 |
| segher | current code uses IN_RANGE | 00:53 |
| segher | which is inclusive | 00:53 |
| lxo | since when? | 00:53 |
| segher | since always | 00:53 |
| lxo | the patch is from last week's codebase | 00:53 |
| lxo | so, no, you're mistaken about what the code uses right now. at least in that place | 00:54 |
| lxo | and there are lots of such hunks in the patch | 00:54 |
| segher | there is nothing else that uses LAST_FPR_REGNO | 00:54 |
| lxo | you understand what '-' and '+' mean in a patch, right? | 00:54 |
| lxo | the line with the literal 64 is what was there before I changed it to use some meaningful symbolic constant | 00:55 |
| segher | no need tto be insulting, lol | 00:55 |
| segher | and it is not nmore meaningful | 00:55 |
| segher | there are 32 FPRs. this has been part of the architecture since forever | 00:56 |
| segher | i also do not write "c" when i mean light speed. i just write "1" | 00:56 |
| lxo | so which FPR is 64 again? | 00:56 |
| programmerjake[m | well, with SimpleV, there are 128 fprs | 00:56 |
| segher | there is no 64 | 00:56 |
| segher | this loops to 63 as last | 00:56 |
| segher | i do not write 63 + 1 | 00:56 |
| lxo | want me to post the line that has 64 in there again so you'll see it? | 00:56 |
| segher | because that is just dumb | 00:56 |
| programmerjake[m | future versions of SimpleV may expand the number of registers to 256 or 512 | 00:58 |
| segher | and that is very problematic | 00:58 |
| segher | but, bedtime. cyal | 00:59 |
| lxo | programmerjake[m, that's not really relevant for purposes of the patch. I'm just introducing uses of mnemonic constants instead of ambiguous literals | 00:59 |
| lxo | nite | 00:59 |
| programmerjake[m | gn | 01:00 |
| programmerjake[m | lxo: it's relevant to not getting used to gcc's internal register numbers remaining fixed... | 01:00 |
| lxo | true, but we don't need those extra registers to be in the middle of preexisting files | 01:01 |
| programmerjake[m | k | 01:03 |
| lxo | like, we *could* add fr32..fr127 right after r32..r127 | 01:03 |
| lxo | it would prevent vectors from crossing the 31/32 boundary, but that's probably not a big deal | 01:03 |
| programmerjake[m | yup, but that probably makes allocating ranges more complex | 01:03 |
| lkcl | segher: we\re extending scalar INT, FP and CRs all to 128 entries. this is a bare minimum for a 3D GPU. | 01:05 |
| lxo | r31 is usually not available for allocation anyway, so it's no big deal there. for FP, it could be useful to cross that boundary, but not critical. cr7/cr8 might be the most critical boundary | 01:06 |
| lkcl | not crossing over from 31/32 might actually be cleaner, but also just a quirk that's covered by reg allocation | 01:08 |
| programmerjake[m | hmm, in the code I've seen, r31 is rarely used, so it should be free most the time | 01:09 |
| lxo | remember that gcc ra allocates to *contiguous* registers | 01:09 |
| programmerjake[m | most code doesn't need r31 since the stack frame isn't variable-sized | 01:10 |
| lxo | ^lkcl | 01:10 |
| programmerjake[m | I personally think that we should just renumber gcc's internals -- producing worse code because of sw bickering seems like the wrong direction... | 01:12 |
| lxo | I agree, and that's what I implemented. that got me to notice the literals, even | 01:13 |
| lxo | but it's not the end of the world if we get pushback from upstream on these grounds | 01:13 |
| programmerjake[m | yeah | 01:14 |
| programmerjake[m | I would even go as far as replacing the register number type with an enum... | 01:16 |
| lxo | it might even be sensible to leave the "legacy" registers for use as scalars, with shorter opcodes, and use the extended registers primarily for vectors. this break at 31/32 wouldn't likely only make for significant differences in corner cases and tests intended to trigger it | 01:16 |
| programmerjake[m | enum: though that could be a lot of work | 01:17 |
| lxo | using enum as array index is iffy | 01:17 |
| programmerjake[m | at this point, with the `#define`s and the integer type, sounds like a poor-man's enum to me | 01:19 |
| lxo | what define? | 01:20 |
| lxo | there's a define_constant in rs6000.md that introduces the constants I'm talking about | 01:20 |
| programmerjake[m | LAST_FPR_REGNO | 01:21 |
| lxo | in C code, they become #defines indeed, but they have integral types, not enum types, so they can be used to index arrays, which GCC does a lot with internal register numbers | 01:21 |
| programmerjake[m | if it's a const instead of a define, it's still essentially the same | 01:22 |
| lxo | (LAST_FPR_REGNO159) | 01:22 |
| programmerjake[m | don't see why you can't index arrays with C-style enums... | 01:22 |
| programmerjake[m | enum class ... harder | 01:22 |
| lxo | uhh, I was pretty sure there was some warning or error against using an enum constant as an array index, but maybe I'm mistaken | 01:25 |
| programmerjake[m | https://gcc.godbolt.org/z/YKhfE9 | 01:25 |
| programmerjake[m | nothing with -Wall | 01:25 |
| lxo | there's nothing fundamentally wrong with it, I just thought there was some rule against it | 01:26 |
| lxo | maybe it's just some style thing somewhere | 01:26 |
| programmerjake[m | C enums are pretty close to typedef int E, so I see no issue | 01:26 |
| programmerjake[m | stackoverflow seems to think it's fine: https://stackoverflow.com/a/404263 | 01:29 |
| lxo | I'm pretty sure there's some pitfall there, involving C or C++, but I unfortunately can't recall what it is | 01:32 |
| lxo | maybe it has to do with -fshort-enum, which is enabled by default in some ABIs | 01:33 |
| programmerjake[m | that's what `enum E : int {` fixes | 01:33 |
| lxo | yeah, but that's C++ only | 01:34 |
| programmerjake[m | isn't gcc compiled in C++? | 01:34 |
| lxo | most of it, yeah | 01:37 |
| programmerjake[m | also, even if short-enum is enabled, all you need is to add another enumerant: `LAST = 0xFFFFFFFFL` | 01:37 |
| awygle | lkcl: if you still want me to work on the partition thing, I'm game | 01:40 |
| lxo | programmerjake[m, anyway... the bits that define symbolic names for registers, so that they can be used in both C/C++ sources and the LISP-ish ones, are in LISP-ish machine descriptions | 01:41 |
| programmerjake[m | ah, ok. that might make it harder, but it still may be a worthy goal for sometime, not now | 01:43 |
| programmerjake[m | too bad .md is usually interpreted as markdown... | 01:43 |
| programmerjake[m | except on libre-soc's wiki, where .mdwn must be used, because ikiwiki | 01:44 |
| lxo | I think gcc already used .md files before aaron was even born | 01:50 |
| programmerjake[m | yeah, hence why I didn't say: too bad gcc devs didn't check for well-known file formats before picking file extensions | 01:52 |
| programmerjake[m | though it might be a good idea to rename them if it doesn't cause too much trouble... | 01:52 |
| programmerjake[m | .mdes anyone? | 01:53 |
| programmerjake[m | or is gcc trying to still build on ms-dos? | 01:54 |
| lxo | nah, this sort of pointless cosmetic change just makes it harder to merge changes across branches. not going to happen. we still use .c for souce files that used to be in C | 01:54 |
| lxo | I haven't heard of DJ's giving up on DJGPP | 01:55 |
| lxo | me, I like .mdwn :-) | 01:56 |
| programmerjake[m | yeah, but isn't that mostly a cross-compiler? and it requires non 8.3 file name support? | 01:56 |
| programmerjake[m | me, i like .md since that's default in most editors | 01:57 |
| lxo | I'm pretty sure djgpp was native, but I don't think I've ever used it | 01:57 |
| programmerjake[m | i did, wrote a sw 3d renderer using vesa vbe with it | 01:58 |
| lxo | when I open a GCC .md file with the one true editor ;-) it selects lisp mode | 01:58 |
| programmerjake[m | https://github.com/programmerjake/djgpp-test3d | 01:59 |
| programmerjake[m | probably your editor uses heuristics to detect it | 01:59 |
| lxo | by the time I came across GNU, I switched over to it (on Unix systems), and didn't really look back to DOS | 02:00 |
| lxo | (add-auto-mode "\\.md\\'" 'lisp-mode) ;; <-- heuristics. I had no recollection of having added this bit to my .emacs. it's been a while :-) | 02:01 |
| programmerjake[m | i mostly used dos for raw hw access | 02:01 |
| lxo | I used DOS between 1985 and 1991 | 02:02 |
| lxo | I wrote a bunch of TSR programs like keyboard accelerators and accent-prefix combiners for various "standards" that existed back then | 02:04 |
| programmerjake[m | one true editor: obligatory xkcd reference: https://xkcd.com/378/ | 02:05 |
| lxo | :-) I often make fun when others label emacs as an editor. it's an heresy. vi is an editor. emacs is a development environment, almost an operating system | 02:06 |
| programmerjake[m | I used dos well past then, mostly switching to linux by 2012 | 02:07 |
| programmerjake[m | though it was mostly dos from in win xp | 02:08 |
| lxo | I've used gnu since 1991, but only started using gnu/linux on 1996 | 02:08 |
| lxo | I managed to avoid windows :-) | 02:08 |
| programmerjake[m | i started using linux when I got a dual-socket pentium 4 with 64-bit support, didn't have a 64-bit version of windows, so installed linux | 02:09 |
| programmerjake[m | though I did use it some before then | 02:10 |
| lxo | I haven't used linux for 13 years | 02:11 |
| programmerjake[m | only gnu/linux? ;) | 02:11 |
| lxo | no, I started using linux-libre then | 02:12 |
| programmerjake[m | ah, well I still count that as a linux variant | 02:12 |
| lxo | I wish people who referred to the operating system as linux would agree with that kind of perspective and call it gnu | 02:14 |
| programmerjake[m | not to be confused with gnu hurd... | 02:14 |
| lxo | no, that's another gnu kernel | 02:15 |
| programmerjake[m | well, we live in the world of often-ambiguous overlapping terminology... earlier today, for Rust's SIMD working group, we agreed that element/lane are equivalent | 02:17 |
| lxo | point is that people who will deny to their graves that they use a gnu system have no whims whatsoever admitting that it's a unix system | 02:18 |
| programmerjake[m | but lkcl thinks that lanes are nearly antithetical to SimpleV and elements are correct... | 02:18 |
| programmerjake[m | I won't deny that it's gnu, but I still use the commonly accepted alias "linux" for gnu/linux | 02:19 |
| lxo | you're entitled to choose which ideology you wish to endorse and promote | 02:20 |
| lxo | (or lack thereof) | 02:20 |
| programmerjake[m | though that leads to confusion when describing android ... bionic/linux? | 02:20 |
| lxo | the operating system name is android | 02:21 |
| programmerjake[m | java/linux | 02:21 |
| programmerjake[m | wait, i know, ad-distribution-platform/linux | 02:21 |
| lxo | linux was initially intended as a kernel to work with gnu userland, but it was later adopted as the kernel underneath android as well | 02:22 |
| programmerjake[m | yup! | 02:22 |
| lxo | earlier, it seems that it was conceived of as a full operating system, but that was abandoned in favor of developing just a kernel | 02:23 |
| programmerjake[m | hmm, didn't know that | 02:23 |
| programmerjake[m | well, debian does/did also have gnu/kfreebsd | 02:24 |
| programmerjake[m | iirc | 02:24 |
| lxo | and there was a distribution of gnu with the opensolaris kernel, and IIRC there was even a gnu/darwin one | 02:26 |
| lxo | early on, linus often compared the kernel and his plans with gnu and minix, but linux is how he names the tarballs of the kernel he started | 02:27 |
| programmerjake[m | i think there's even a few more x/linux OSes out there | 02:28 |
| lxo | I'm curious whether F*csia :-) will have linux as the kernel | 02:30 |
| lxo | https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 is quite enlightening to read and get a perspective of how things looked before history started being rewritten | 02:32 |
| lxo | this was from a time when linux was anti-commercial (thus non-free) | 02:34 |
| programmerjake[m | iirc fuschia has it's own kernel | 02:39 |
| lxo | that's my impression as well | 02:41 |
| lxo | fuschia is an interesting way to spell it. it sounds like fusca, the way the volkswagen beetle is called in brazil | 02:41 |
| lxo | the original beetle | 02:42 |
| lxo | I still prefer the f*chsia expletive ;-) | 02:42 |
| programmerjake[m | idk, it's named after a color, most of the weird and wonderful color names are incomprehensible to me... | 02:43 |
| programmerjake[m | if we're taking about weird OSes, I'm a little partial to Redox OS: https://www.redox-os.org/ | 02:46 |
| programmerjake[m | was daydreaming with cole a while ago about having kazan ported to Redox, first accelerated 3D graphics for Redox would be Libre-SOC :) | 02:47 |
| sorear | it's Fuchsia, named after a mr. Fuchs, normal german name and dictionary word | 02:48 |
| programmerjake[m | ah, ok | 02:48 |
| programmerjake[m | one of the coal tar chemists of the 1800s I presume? | 02:49 |
| lxo | fuchsia also names a flower, whose typical color is referred by the same name | 02:50 |
| sorear | Leonhart Fuchs (German: [ˈfʊks]; 17 January 1501 – 10 May 1566), sometimes spelled Leonhard Fuchs,[1] | 02:50 |
| sorear | plausible but no | 02:50 |
| programmerjake[m | wow, much earlier than expected! | 02:50 |
| lxo | sorear, is this a fact, that fuchsia is named after a mr fuchs? | 02:52 |
| lxo | fuchsia the operating system, I mean | 02:52 |
| sorear | fuchs (man) -> fuchsia (flower) -> fuchsia (color) -> fuchsia (OS) | 02:52 |
| sorear | https://fuchsia.googlesource.com/fuchsia/ "Pink + Purple == Fuchsia" | 02:53 |
| sorear | presumably the man was named after fuchs (fox) | 02:54 |
| programmerjake[m | fuchs (man) -> fuchsia (flower) -> fuchsine (chemical) / fuchsia (color) -> fuchsia (OS) | 02:54 |
| programmerjake[m | I *knew* there was some 1800s chemist involved... | 02:55 |
| programmerjake[m | XD | 02:55 |
| lkcl | programmerjake[m, i don't. they're also interchangeable terminology. please do try not to assert things i haven't said! | 10:33 |
| lkcl | awygle, superb, yes please | 10:33 |
| lkcl | could you send me an ssh key by email, to lkcl@lkcl.net, and an appropriate email address you're happy to have in the bugtracker (i can set up a redirect through libre-soc.org if you prefer, i did that for lxo) | 10:38 |
| programmerjake[m | lanes/elements: ok, well it had seemed that way to me before... | 10:39 |
| programmerjake[m | I think what had happened is I was using the term lanes which had somehow confused lkcl into thinking I meant we should implement a x86-style SIMD instruction set or something, that was all cleared up several months ago when it happened. sorry lkcl, didn't mean to put words into your mouth | 10:57 |
| programmerjake[m | didn't see when it happened after some quick searching, so just going off my memory | 10:58 |
| lkcl | the confusion probably stems from a long time ago when we were discussing traditional vector architectures | 11:00 |
| lkcl | given that we're now doing predicated SIMD back-ends the lines are blurred and the terminology - wording used - is irrelevant/interchangeable | 11:01 |
| programmerjake[m | ok, sounds good! | 11:02 |
| lkcl | where the distinction _will_ be needed is when multi-issue comes into play | 11:02 |
| lkcl | because, there, if you have QTY 2 4-wide SIMD back-ends, elements 0 and 4 will be allocated to Lane ZERO of SIMD-FU-1 and Lane ZERO of SIMD-FU-2 respectively | 11:03 |
| lkcl | elements 1 and 3 to lane ONE of SIMD-FU-1 and SIMD-FU-2 | 11:03 |
| lkcl | etc. etc | 11:03 |
| programmerjake[m | hmm, for reduction of confusion I think we should have lanes/elements be exactly equivalent at ISA and SW levels | 11:03 |
| lkcl | but a single-issue in-order system, or a programmer, won't know and won't care. | 11:03 |
| lkcl | that would make it impossible to talk, in hardware terms, about even the existence of SIMD Function Unit 1 and 2. | 11:04 |
| lkcl | from a programmer perspective, there's no difference, they don't care and shouldn't have to care. at all. | 11:04 |
| lkcl | from a *programmer* perspective, even the *existence* of the two SIMD function units in an OoO microarchitecture is entirely transparent | 11:05 |
| lkcl | so from a *programming* perspective, the fact that the Rust subcommittee on SIMD has determined that there is no difference between Lanes and Elements is a perfectly valid perspective | 11:06 |
| programmerjake[m | the only way a programmer would care is execution time | 11:06 |
| lkcl | but from a *hardware* perspective it absolutely is *not* correct to conflate the two. | 11:06 |
| lkcl | both perspectives are however perfectly correct... *in their context* | 11:07 |
| lkcl | yehyeh | 11:07 |
| programmerjake[m | ok, though I think referring to lanes/elements as equivalent words even in a hw context can be helpful, to refer to lane/element 1 of a simd alu, you'd write element 1 of simd alu #1, to refer to lane/element 1 of the ISA-level instruction, you'd write element 1 of ISA-level instruction. or something... | 11:10 |
| programmerjake[m | anyway, gtg, time for me to sleep | 11:11 |
| lkcl | :) | 12:06 |
| segher | lxo: r31 *is* available for allocation | 12:41 |
| segher | and changing that specific code to not use the fixed numbers is completely wrong: it is ABI! | 12:42 |
| segher | this is related to the problem with calling 32 FP... in many cases 32 is VSR, instead | 12:43 |
| segher | it is still the same register | 12:43 |
| segher | just how it is used differs | 12:44 |
| segher | 32..95 are the 64 VSR registers | 12:44 |
| segher | it is very important (for compiler performance) that these are contiguous | 12:44 |
| programmerjake[m | maybe it would help if we used my idea of having SimpleV based on 64x 128-bit registers instead of 128x 64-bit registers, that would map 1:1 to VSR regs | 12:48 |
| segher | either way, before we can accept anything like this in GCC, you'll need to have the ABI defined | 12:57 |
| segher | you can experiment with it outside of trunk of course | 12:58 |
| lkcl | segher: we're preserving full backwards compatibility with scalar v3.0B and very very specifically not going outside of function calls for now | 14:33 |
| lkcl | so the ABI is defined as, "the ELF v1 ABI" or "the ELF v2 ABI" | 14:33 |
| lkcl | or "the-current-ABI-that-is-used-for-OpenPOWER-v3.0B" | 14:33 |
| lkcl | at some point we'll be in a position to define an ABI that crosses function-call boundaries, has its own triplet and/or is part of an "option" for a future revision of ELF V2... | 14:35 |
| lkcl | ... but this is itself such a vast amount of work that we cannot delay proceeding just because of it | 14:35 |
| lkcl | *our funding from NLnet ends at the end of this year* | 14:36 |
| lkcl | so we need to be a bit smart / careful about "what we take on" if you know what i mean | 14:55 |
| segher | lkcl: no | 15:49 |
| segher | for the abi, you need to define the DWARF numbers for all your registers, for example | 15:49 |
| segher | abi is so much more than calling convention | 15:49 |
| segher | lkcl: i understand the difficult position you are in | 15:50 |
| segher | but a project like GCC cannot afford to dedicate huge resources to something that does not even have a defined ABI yet | 15:51 |
| segher | (and it is not just GCC) | 15:51 |
| lkcl | nngghhhh ok :) | 16:19 |
| * lkcl deep breath, deep breath. i am in the centre of the lake. i am the lake. caaalm waters... | 16:19 | |
| lxo | lkcl, that's ok, I got those bits covered in my patch under development | 17:32 |
| lxo | indeed, it may very well be the case that the bug I mentioned I'm hunting down, that affects unwinding through signal frames, is failure to map some renumbered register back to the ABI-defined number | 17:34 |
| lkcl | lxo: iinteresting | 18:05 |
| * lkcl glad you're on the case | 18:06 | |
| programmerjake[m | lxo: maybe try and build a function that uses all the registers, then look at the code with a debugger and see if the registers match up correctly | 18:15 |
| programmerjake[m | at the generated output code | 18:16 |
| lxo | programmerjake[m, I don't think it's any of the regular registers; those are remapped properly | 20:38 |
| lkcl | meeting 5mins | 21:55 |
| lkcl | programmerjake[m, ^ | 21:55 |
| lkcl | lxo, ^ | 21:55 |
| programmerjake[m | :) | 21:56 |
| mepy | How is going? | 22:39 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!