00:00:00 --- log: started forth/20.05.03 00:21:03 --- join: rdrop-exit joined #forth 00:25:51 What could possibly be formulaic about C at all? Especially compared to Forth? 00:26:25 I don't understand the question 00:26:54 Zarutian_HTC claims C makes any sense. 00:28:24 I've decided to reject any description of anything that's comprised of less than 100 words ... 00:29:05 it's the 'tp hypothesis' 00:31:22 I ignore any comparisons to Forth that treat Forth as if it were merely a programming language 00:33:23 irrespective of what the ANS standard people would have you believe 00:36:35 "The rage springs not so much from a sense that Forth violates certain well-established rules and conventions as from the suspicion that Forth proves that many of these rules and conventions are meaningless" -- Jack Woehr 00:39:02 "Forth is a complete system. It is a self-contained operating system, multitasking executive, editor, 00:39:05 command-line parser, compiler, interpreter, assembler, decompiler, debugger." -- Jack Woehr 00:44:46 so here is where I am with my Keil C and svd2forth comparison http://dpaste.com/1KB8ER6 00:45:00 this is just a short summary 00:45:03 Thanks rdrop-exit! 00:45:25 my pleasure :) 00:45:39 RATC (Rage Against The C) 00:46:29 firstly I was surrised that Keil C resort to thousands of #defines when it comes to register bitfields 00:46:48 it leaves me feeling that C is a solution looking for a problem 00:47:15 what did you expect? 00:47:39 I had no expectations, I try to be open minded 00:48:37 Everytime I look at a particular C 'solution' I seem to find every vendor has a different embedded approach 00:49:24 You forgot to show the definition of RCC_CFGR 00:49:43 on the Forth side 00:49:50 Keil see fit to predefine *every* configuration possibility or at least as many as they can 00:50:15 combinatorial explosion? 00:50:17 as always it's a memory address 00:51:24 given the possible massive number of combinations I think it's a loosing error prone strategy 00:51:24 tp: Conflict of Interest? I bet those ""header files"" were ""automatically generated"". 00:52:06 tp, ok but you're not showing the reader that definition 00:52:08 DKordic, my Forth definition is automatically generated from the CMSIS-SVD, I'm not sure about the C stuff 00:53:26 DKordic, there are lots of workarounds throughout the stm32f051x8.h that cant be automatic imho 00:53:49 some of the peripherals have too many interconnecting parts 00:54:42 tp: IMHO ""automatically generated"" is an ID10Tic BuzzWord. Wouldn't ""transformed"" or ""derived from"""? 00:54:55 I thought I'd find that Keil do something similar to what I do 00:56:10 ""automatically generated"" was a bloody red warning every time. 00:58:08 --- join: merkc0 joined #forth 00:59:05 http://sourceware.org/cgen/ is the most tragy-comical example. 01:00:00 http://ctags.sourceforge.net/ is Perl in C(11) (not AutoGen). 01:00:20 DKordic, I'm a tech, I lack the correct programmer terminology 01:00:55 CTAGS is W:Greenspun's_tenth_rule of C(11) in C(11) itself!! 01:01:15 tp: Just my 2 cents :3 . 01:02:06 DKordic, I wrote the XSLT transforms, and they use data 'derived from', but I do it all automatically ;-) 01:02:53 DKordic, with shell scripts 01:03:47 so who has a theory why Keil use #defines ? 01:04:29 is it because C lacks a better way, or is it a 'better way' ? 01:06:43 it's often the simplest way, sometimes it makes more sense to use a const 01:07:46 rdrop-exit, is this another level of abstraction ? 01:08:21 #defines are macro processor directives, no abstraction, just source text preprocessing 01:08:38 rdrop-exit, my understanding is that the C compiler doesnt know about #defines which are 'pre-processed' before C gets the header ? 01:09:31 as the code is preprocessed, it seems like a abstraction to me 01:10:09 for instance, the API ? is more or less a summary of the #define 01:10:17 it's just text replacement 01:10:26 #define FOO 7 01:10:27 --- join: Guest59598 joined #forth 01:10:38 x+=FOO; 01:10:56 is handed to the compiler as x+=7; 01:11:06 I ask because I observe again and again that embedded C programmers have almost no understanding of bitfields or their use 01:12:00 and I was coming to the conclusion that something shields them from bitfields 01:12:00 that may have more to do with the programmers you're speaking too, than any aspect of C, don't know 01:12:35 yeah, it's that thinl line between programmers and hardware people 01:14:01 C programmers are often shielded from the actual bitwidth of a variable, unless they define their variables using the specific bitwidth, e.g. uint32_t 01:14:39 yes, that also makes sense 01:15:42 e.g. for constants UINT32_C 01:16:31 I almost never use the run of the mill, int, long, short, etc... 01:17:27 In all my C code I have abbreviations for the specific bitwidths 01:17:41 e.g. 01:17:43 #define I64 int64_t 01:17:43 #define U8 uint8_t 01:17:43 #define U16 uint16_t 01:17:45 #define U32 uint32_t 01:17:48 #define U64 uint64_t 01:17:50 #define U32C UINT32_C 01:17:53 #define U64C UINT64_C 01:19:17 a forth horror story, https://twitter.com/geepawhill/status/1256342997643526151 01:20:07 --- quit: Guest59598 (Changing host) 01:20:07 --- join: Guest59598 joined #forth 01:20:49 --- nick: Guest59598 -> presiden 01:21:35 Here's an example: 01:21:37 SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); } // branchless 01:22:30 oops missed the comments, just a sec 01:22:48 SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); } // branchless 01:23:04 damn it won't copy comments for some reason 01:23:58 --- quit: rdrop-exit (Quit: Lost terminal) 01:24:42 --- join: rdrop-exit joined #forth 01:24:49 trying agin 01:25:05 Binary logarithm (ceiling). 01:25:11 *** N.B. clog2(0)==0 *** 01:25:20 SI U8 clog2(U64 u){ return 64-nlz64(u-!!u); } 01:26:47 SI is static inline 01:31:57 --- quit: rdrop-exit (Read error: Connection reset by peer) 01:35:04 --- join: rdrop-exit joined #forth 02:03:21 --- join: dddddd joined #forth 02:14:11 presiden: I literally was about to post this here 02:14:27 I can't help but read it and think "what a moron" and "why did you tell us this" 02:15:29 I get that he was trying to be helpful but this story makes me seethe at him, I would never ever release software personally or in a company writing raw blocks to a drive without understanding the layout and boundaries of the drive... 02:16:49 This is the kind of mistake that puts you out of business in a sane world 02:21:49 And annoying I'm 100% sure that there are people that will save this as an example of "why to avoid forth" or "why forth is bad" 02:21:59 annoyingly* 02:22:58 I literally just applied the forth block model to some code at work, because it elegantly describes caching with enough inference to be faster than some kind of dumb caching abstraction 02:23:31 Am I overwriting someone's data? No, because I know the *format* and *layout* of what I'm writing to. I can't imagine not knowing that when writing raw blocks.... 03:02:37 --- join: mayuresh joined #forth 03:02:51 --- quit: mayuresh (Client Quit) 03:09:38 --- join: jsoft joined #forth 03:17:13 --- quit: rdrop-exit (Quit: Lost terminal) 03:18:12 --- join: rdrop-exit joined #forth 03:20:02 "Une grande responsabilite' est la suite inse'parable d'un grand pouvoir." -- Voltaire 03:20:41 veltas, I agree 03:25:01 --- join: TCZ joined #forth 03:29:24 --- quit: jsoft (Ping timeout: 264 seconds) 03:36:24 --- quit: _whitelogger (Remote host closed the connection) 03:37:08 --- nick: jedb_ -> jedb 03:39:28 --- join: _whitelogger joined #forth 04:01:57 --- quit: TCZ (Quit: Leaving) 04:04:08 --- quit: rdrop-exit (Quit: Lost terminal) 04:59:32 --- join: jsoft joined #forth 05:10:15 --- join: TCZ joined #forth 05:13:46 --- quit: TCZ (Client Quit) 05:56:25 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 05:56:36 --- join: Zarutian_HTC joined #forth 06:47:45 --- quit: iyzsong (Ping timeout: 260 seconds) 07:45:36 --- quit: merkc0 (Ping timeout: 264 seconds) 08:03:32 --- quit: gravicappa (Ping timeout: 265 seconds) 08:17:33 --- quit: Zarutian_HTC (Ping timeout: 265 seconds) 08:21:05 --- quit: jsoft (Ping timeout: 260 seconds) 08:49:10 tp, do you replace all those #defines from Keil with Forth words? 09:02:21 --- join: Zarutian_HTC joined #forth 09:22:25 --- join: gravicappa joined #forth 09:28:21 MrMobius, I do, but they're derived from the STM32 CMSIS-SVD for each MCU type using XSLT transforms 09:28:42 (my thanks tp DKordic for the correct terminology) 09:28:50 tp = to 09:29:39 tp, how much firmware space does that take? 09:31:10 MrMobius, the firmware space required varies as my system allows the generation of this data on a per peripheral basis 09:31:52 so it wont store words for peripherals you arent using? 09:33:58 MrMobius, correct, and even then although I tend to load all the generated memory map words during development and select bitfield words by hand, I'm working on a parser that eliminates non used words 09:35:21 this is for resident a resident forth, a tethered Forth doesnt have that issue as only the generated stand alone binary is mcu resident 09:37:01 MrMobius, but even the tether I use for msp430 uses the same words derived from a CMSIS-SVD for MSP430 type using XSLT transforms 09:37:23 lol, because the tethered host is a arm cortex-m4 09:38:11 talk about cross polination! 10:29:57 --- join: dys joined #forth 10:58:07 --- join: reepca joined #forth 11:12:27 --- quit: reepca (Read error: Connection reset by peer) 11:12:43 --- join: reepca joined #forth 12:41:50 --- quit: boru (Ping timeout: 260 seconds) 12:48:33 --- join: boru joined #forth 12:55:13 --- quit: boru (Ping timeout: 256 seconds) 12:58:35 --- join: boru joined #forth 14:20:10 --- join: dave0 joined #forth 14:31:39 --- join: TCZ joined #forth 14:56:00 --- quit: jpsamaroo (Ping timeout: 265 seconds) 15:08:39 --- quit: gravicappa (Ping timeout: 272 seconds) 15:54:22 --- join: jsoft joined #forth 15:59:26 --- quit: TCZ (Quit: Leaving) 16:46:58 --- join: TCZ joined #forth 17:06:40 --- quit: jsoft (Ping timeout: 260 seconds) 17:09:16 --- join: iyzsong joined #forth 17:09:46 --- quit: reepca (Read error: Connection reset by peer) 17:10:23 --- join: reepca joined #forth 17:15:27 --- join: jsoft joined #forth 17:58:04 --- quit: TCZ (Quit: Leaving) 18:11:14 --- join: X-Scale` joined #forth 18:12:42 --- quit: X-Scale (Ping timeout: 258 seconds) 18:12:43 --- nick: X-Scale` -> X-Scale 18:16:31 --- join: boru` joined #forth 18:16:34 --- quit: boru (Disconnected by services) 18:16:37 --- nick: boru` -> boru 18:21:25 --- quit: _whitelogger (Remote host closed the connection) 18:24:28 --- join: _whitelogger joined #forth 19:07:34 --- quit: dave0 (Quit: dave's not here) 19:26:06 --- quit: dddddd (Remote host closed the connection) 20:15:36 --- quit: proteus-guy (Ping timeout: 246 seconds) 20:45:36 --- quit: jsoft (Ping timeout: 240 seconds) 21:08:22 --- join: jsoft joined #forth 21:10:30 --- join: proteus-guy joined #forth 21:11:44 --- quit: proteusguy (Ping timeout: 258 seconds) 21:23:49 --- join: proteusguy joined #forth 21:23:49 --- mode: ChanServ set +v proteusguy 21:30:20 --- quit: proteus-guy (Ping timeout: 260 seconds) 22:08:47 hi all, Ive finally finished my brief article on Keil C v/s Forth, peripheral configuration: https://mecrisp-stellaris-folkdoc.sourceforge.io/peripherals-c-vs-svd2forth.html#cvssvd2forth 22:15:46 nice 22:17:19 presiden, thanks, it is a bit superficial at this point but I really just wanted to show the differences each language takes 22:17:47 the different approaches I mean 22:35:01 --- join: gravicappa joined #forth 23:12:08 --- join: proteus-guy joined #forth 23:45:01 --- join: mtsd joined #forth 23:59:59 --- log: ended forth/20.05.03