| lkcl | whoops he's gone | 00:51 |
|---|---|---|
| lkcl | if you see this in irc logs: yes, and they can always be altered later | 00:51 |
| lkcl | cesar, i had an idea: how about creating a tiny (dummy) core using alu_hier.py? | 14:17 |
| lkcl | really *really* basic. "decoder" just does 1<<x on its "instruction" which is a 2-bit number | 14:19 |
| lkcl | the "core": if bit 0 is set, do an add, if bit 1 is set, do a "branch" | 14:19 |
| lkcl | branch-immediate only | 14:19 |
| lkcl | or just... everything is immediates, and the "core" drops its result (alu.o), does nothing with it | 14:20 |
| lkcl | "instructions" are read from a combinatorial Array, only say... 16 entries, containing a Record with the 2-bit "instruction", and 2 4-bit immediates | 14:22 |
| cesar | lkcl: Sure, but why? | 15:45 |
| cesar | I guess it would allow writing unit tests for developing the pipelined Fetch unit... | 16:30 |
| lkcl | yes, in a much smaller codebase | 16:59 |
| lkcl | i think i have the bug tracked down for the dcache.py error: soc.vhdl requests 64 cache lines, the default in dcache.vhdl is 32. | 17:02 |
| lkcl | linux kernel expects 64, and writes *overlapping* TLB entries into cache lines. whoops | 17:02 |
| lkcl | ghostmansd[m], have you used autoconf before? it's quite straightforward | 20:34 |
| lkcl | there will be a config.h.in file into which you put #undef HAVE_WHATEVER | 20:35 |
| lkcl | then adding that option to configure.ac will "work" | 20:35 |
| lkcl | best thing to do is find something "reasonably similar" and cut/paste all occurrences of that | 20:35 |
| lkcl | but the important one not to miss is that config.h.in which you will find listed in configure.ac as a target that gets rewritten (macro-substed) | 20:36 |
| lkcl | by running autoconf that config.h.in auto-generates a config.h | 20:37 |
| lkcl | over the past 25 years i've done half a dozen projects with it - samba, freedce, python, webkit - so am used to it | 20:38 |
| ghostmansd[m] | I've not used it personally. Checked the output, yes. Rewrote the gnulib in Python, for sure. But using it is somewhat, well, exceeding the limits of my patience. | 20:50 |
| ghostmansd[m] | Every time I have to take a look at it is as if I see it for the first time, lol | 20:51 |
| ghostmansd[m] | But I have the same issue with regex, so I assume this is just a personal glitch | 20:51 |
| lkcl | it's about a... 4-stage process. don't for goodness sake try to "learn" autoconf, go with a "pattern-matching" approach | 20:53 |
| ghostmansd[m] | Sure won't | 20:53 |
| lkcl | find something correspondingly similar, grep for all occurrences of that #define feature, and literally cut/paste | 20:53 |
| lkcl | if you get really stuck i'll help out | 20:54 |
| ghostmansd[m] | Ok, it's a deal! :-) | 20:55 |
| * lkcl just coming up to yet another crunch-point for dcache debugging in verilator | 20:55 | |
| lkcl | about another 500,000 to 1,000,000 instructions to go | 20:56 |
| ghostmansd[m] | I think the thing basically boils down to two parts: | 20:56 |
| ghostmansd[m] | 1. We need configure.ac to place #define SVP64 in config.h; | 20:56 |
| ghostmansd[m] | 2. We need to adjust build system to build some code depending on whether SVP64 is active. | 20:56 |
| ghostmansd[m] | Basically the only obstacle here is autotools, frankly speaking | 20:57 |
| ghostmansd[m] | But that's not the first time I deal with it, so no way we surrender :-) | 20:58 |
| lkcl | it really isn't an obstacle. it's extremely sophisticated and mal-aligned by people who don't understand its purpose: low-level portability across literally any system | 20:58 |
| * lkcl trying to remember... ok config.h.in is autogenerated by configure.ac | 20:59 | |
| lkcl | so you should *expect* to see (once the correct voodoo incantation is added to configure.ac) a bunch of "#undef HAVE_XXXXX" entries in config.h.in | 21:01 |
| lkcl | which when running autoconf will generate corresponding "#define HAVE_XXXX" entries in config.h | 21:02 |
| ghostmansd[m] | > by people who don't understand its purpose | 21:02 |
| ghostmansd[m] | It's like what I'm thinking of make. Almost anytime I see makefile people invent a brand new build system out of simple stupid tool capable of "I can track dependencies, and hey, I can also check for timestamps" | 21:02 |
| lkcl | rrriiight. | 21:03 |
| ghostmansd[m] | I mean, hey, to me it looks like that people don't understand that make is _not_ a build system | 21:03 |
| lkcl | my favourite one there was someone - and i swear that this is genuine - writing and submitting a patch to python to replace autoconf with scons. | 21:03 |
| lkcl | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=configure.ac;h=2b10e9a1b0260668cc3851ecfa04d59210d6eca0;hb=refs/heads/svp64#l3562 | 21:04 |
| ghostmansd[m] | It's a simple pipeline, so to speak. A mere automatuon tool. | 21:04 |
| lkcl | yehyeah no totally get it | 21:04 |
| ghostmansd[m] | Wanna build system? gn, meson, even partually ninja to some degree. | 21:04 |
| lkcl | right, the "--enable-maintainer-mode" voodoo incantation would be a good one to cut/paste copy | 21:04 |
| lkcl | it's just a true/false setting, no "option" passed in, there. | 21:05 |
| ghostmansd[m] | Ok, will check this one | 21:05 |
| ghostmansd[m] | Thanks! | 21:05 |
| ghostmansd[m] | We also have another issue | 21:05 |
| ghostmansd[m] | We extend powerpc_opcode struct... | 21:05 |
| ghostmansd[m] | And, well, we have a new 64-bit int there | 21:06 |
| lkcl | which means a zero needs to get added onto all struct fields, i know... | 21:06 |
| ghostmansd[m] | Yehyeh | 21:06 |
| ghostmansd[m] | I went with pragma for no2 | 21:07 |
| ghostmansd[m] | *now | 21:07 |
| lkcl | which is why i think subconsciously i was recommending a uint64_t | 21:07 |
| ghostmansd[m] | Because, well, patch for all these entries is insane | 21:07 |
| ghostmansd[m] | That won't help | 21:07 |
| lkcl | but if you use a union with the struct it'll not need every entry in the bitfield filled out | 21:07 |
| lkcl | union { uint64_t x, struct blah blah { ... }} | 21:08 |
| ghostmansd[m] | Fricking GCC -Wmissing-field-initializers | 21:08 |
| ghostmansd[m] | Yeah, but at least 1 zero is needed | 21:08 |
| ghostmansd[m] | Even for uint64_t | 21:08 |
| lkcl | then set the *union* entry to zero not every single frickin bitfield, it'll be slightly more sane | 21:08 |
| lkcl | yes sensible with the -Warn | 21:08 |
| ghostmansd[m] | And this makes patch bigger a lot than we want | 21:09 |
| lkcl | yyeah | 21:09 |
| * lkcl thinks | 21:09 | |
| lkcl | there is actually a way round it | 21:09 |
| ghostmansd[m] | So I really would like to kick build system's ass | 21:09 |
| lkcl | use a *second* ppc_binutils struct | 21:09 |
| lkcl | where the one that goes into the hashtable has the merged stuff | 21:09 |
| lkcl | but the one with the 10,000 entries does not and is not modified | 21:09 |
| ghostmansd[m] | You mean malloc it? | 21:10 |
| ghostmansd[m] | Different type, kinda C inheritance? | 21:10 |
| lkcl | is it... ahh right, the pointers in the hashtable are just to the static data? | 21:10 |
| ghostmansd[m] | Yes, thought about it... | 21:10 |
| * lkcl haven't looked in a year | 21:10 | |
| ghostmansd[m] | Yep | 21:10 |
| lkcl | arse | 21:10 |
| ghostmansd[m] | Lol | 21:10 |
| * lkcl mumble mumble | 21:11 | |
| lkcl | 2nd hashtable... | 21:11 |
| lkcl | malloc.... | 21:11 |
| lkcl | extend the ppc_binutils struct... | 21:11 |
| lkcl | all "meh" options, darn it | 21:11 |
| ghostmansd[m] | Yeah, kinda `struct powerpc_svp64_opcode { struct powerpc_opcode base; uint64_t ext; }` | 21:11 |
| ghostmansd[m] | And then malloc + memcpy | 21:12 |
| ghostmansd[m] | Not sure of exact place for deallocation, though | 21:12 |
| ghostmansd[m] | But think it's doable | 21:12 |
| lkcl | yuk | 21:12 |
| lkcl | yehyeh | 21:12 |
| ghostmansd[m] | And cast to aggregates starting with common sequence should work | 21:13 |
| ghostmansd[m] | Any compiler which breaks this is a real ass | 21:13 |
| ghostmansd[m] | Still kind hacky | 21:13 |
| ghostmansd[m] | *kinda | 21:14 |
| ghostmansd[m] | Will check all these options. Really think we should keep the patch as decoupled and simple as we can. | 21:14 |
| lkcl | tends to suggest a separate hashtable, doesn't it? | 21:21 |
| lkcl | oleeee! no 0x400 exception, no corrupted TLBs | 21:26 |
| ghostmansd[m] | Frankly, yes. That's why I suggested it before you suggested extending the original powerpc_opcode. :-) | 21:27 |
| lkcl | devtmpfs mounted! | 21:27 |
| ghostmansd[m] | That said, I still think your approach is better. | 21:27 |
| lkcl | ghostmansd[m], i remember. whoops :) | 21:27 |
| ghostmansd[m] | Because otherwise we simply duplicate entries. | 21:27 |
| ghostmansd[m] | Congrats lkcl! | 21:28 |
| ghostmansd[m] | Ok, have to rest for today | 21:28 |
| lkcl | alright sah | 21:29 |
| ghostmansd[m] | Good luck for other stages! | 21:29 |
| ghostmansd[m] | And, as always, a huge thank for help and advice! | 21:29 |
| lkcl | no problem | 21:29 |
| octavius | "people don't understand that make is _not_ a build system", then what should a programmer use to compile a project in, say, C? From my brief reading about Make, I understood that it's more like a scripting language, it runs routines depending on rules | 21:41 |
| octavius | I've been using Make for my toy C code, however I have hit limits on the usability of my makefile | 21:42 |
| lkcl | correct: it "runs routines based on rules" | 21:42 |
| lkcl | it's *not* a "build system" | 21:42 |
| lkcl | therefore "oh look, you can use it *for the purpose of* performing builds" | 21:43 |
| octavius | What *is* a build system? Something that provides dynamic library paths, your code path etc.? | 21:43 |
| lkcl | a build system would, in my mind, be something like... mmm... openembedded. (aka yoctoproject) | 21:43 |
| lkcl | or, buildroot | 21:43 |
| lkcl | which is about 5 or more levels far beyond the "make" command | 21:44 |
| lkcl | or, Eclipse | 21:44 |
| octavius | so is the reason why make can be used for compiling C code because the Linux environment effectively *acts* as the build system? | 21:46 |
| octavius | Because just as easily, shell script can substitute the makefile | 21:46 |
| octavius | However the tools that you mention, give much more flexibility as to which libraries and dependencies you pull in | 21:47 |
| lkcl | no, linux is not a "build system", it is an operating system. you use it to perform a build, by running some commands, but it is a general-purpose "program-runner" | 21:48 |
| lkcl | one of those "programs being run" will happen to *be* a "build system" (such as buildroot, openembedded) but it is a conflation to then consider linux to *be* a build system | 21:49 |
| octavius | ok | 21:49 |
| lkcl | unless of course you set up a dedicated machine | 21:49 |
| lkcl | to which, in your data centre, you give it the one single absolute exclusive purpose, "building a system" | 21:50 |
| lkcl | and oh look the OS happened to be linux | 21:50 |
| lkcl | in which case it would be perfectly reasonable to refer to that machine as "the build system" | 21:50 |
| octavius | But if you just install build-essential, what is it that can be called the build system that is used for C compilation? GCC, ld? | 21:51 |
| lkcl | let's say you replaced make with shell scripts | 21:51 |
| lkcl | and it takes 5 hours to build 50,000 object files | 21:51 |
| lkcl | you then change one header file that requires 3,000 of those object files to be rebuilt. | 21:52 |
| lkcl | how do you identify, in your shell scripts, which object files need to be rebuilt? | 21:52 |
| octavius | You have to check the rules that define the dependencies. A simple shell script doesn't do that | 21:52 |
| lkcl | correct | 21:53 |
| octavius | Whereas a build system would | 21:53 |
| lkcl | now you understand why make exists | 21:53 |
| octavius | ok | 21:53 |
| lkcl | again: you are thinking "too big an all-encompassing box" by using the term "build system" | 21:53 |
| lkcl | you could just use "make" for that purpose i described | 21:54 |
| octavius | But because Make is so open-ended, it was not really optimised for being used just for building | 21:54 |
| lkcl | you do not in any way need a "full build system" | 21:54 |
| lkcl | it's the largest task for which it happens to be put | 21:54 |
| lkcl | because of its amazingly-generic ability to analyse recursive dependencies | 21:55 |
| octavius | Ah ok | 21:55 |
| lkcl | all of this is just... "semantics" or "nit-picking" at one level | 21:55 |
| lkcl | but it is a fine-grain distinction that turns out to be important if you need to know :) | 21:56 |
| octavius | True ;) | 21:56 |
| lkcl | DRAT. the 0x300 exception had simply moved to a different point because of the changes to the cache size | 21:56 |
| lkcl | drat | 21:56 |
| lkcl | it's at least really funny to get a fully-functioning interactive linux kernel debug / monitor prompt | 21:58 |
| lkcl | and, thank god for save/restore breakpoints | 21:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!