00:00:00 --- log: started forth/19.09.08 00:37:24 --- log: started forth/19.09.08 00:37:24 --- join: clog (~nef@bespin.org) joined #forth 00:37:24 --- topic: 'Forth Programming | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th' 00:37:24 --- topic: set by proteusguy!~proteusgu@cm-58-10-209-120.revip7.asianet.co.th on [Wed Jun 26 09:13:14 2019] 00:37:24 --- names: list (clog dys +proteusdude dbucklin gravicappa tabemann rdrop-exit dave0 `presiden tp jedb karswell nonlinear[m] siraben jimt[m] cartwright fiddlerwoaroof djinni chunkypuffs inode lchvdlch pareidolia kori cmtptr MrBusiness3 MrMobius dne lonjil Kumool WilhelmVonWeiner remexre jackdaniel malyn diginet2 Lord_Nightmare nonlinear ecraven yunfan bluekelp dzho cheater louisg Keshl jpsamaroo reepca cp- deesix sigjuice mstevens rann presiden APic catern rprimus +KipIngram) 00:37:24 --- names: list (rpcope alex4nder ovf +crc arrdem amuck guan jhei jn__ irsol phadthai tangentstorm pointfree koisoke gabc) 00:44:38 --- quit: rdrop-exit (Quit: Lost terminal) 02:43:47 --- quit: dys (Ping timeout: 268 seconds) 02:52:09 --- join: dys (~dys@tmo-083-17.customers.d1-online.com) joined #forth 03:33:40 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:49:38 --- quit: karswell (Read error: No route to host) 05:25:08 crc, re FreeBSD, a friend was installing 12.0 today and had some boot errors and a GRUB error message popped up ! ? 05:27:38 "cannot remove da0: root pool can not have removed devices, because GRUB does not understand them" 05:48:19 --- quit: dave0 (Quit: dave's not here) 06:58:58 --- join: X-Scale (~ARM@88.8.43.5.rev.vodafone.pt) joined #forth 07:45:39 --- join: MrBismuth (~ArcMrBism@2600:6c58:4200:ad9:b14a:1f03:d8e3:d6d7) joined #forth 07:48:31 --- quit: MrBusiness3 (Ping timeout: 250 seconds) 09:24:01 tp: that error is actually part of zfs, not grub 09:24:28 https://github.com/zfsonlinux/zfs/blob/master/lib/libzfs/libzfs_pool.c#L3599 09:26:40 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 09:27:25 (FreeBSD 12 pulls from zfsonlinux) 12:03:19 --- quit: dbucklin (Quit: WeeChat 2.3) 12:04:06 --- join: dbucklin (~dbucklin@ec2-18-221-180-137.us-east-2.compute.amazonaws.com) joined #forth 12:23:19 --- quit: gravicappa (Ping timeout: 245 seconds) 13:32:09 --- join: C-Keen (cckeen@k4cg/C-Keen) joined #forth 14:17:35 --- join: Gromboli (~Gromboli@pool-98-118-174-158.bflony.fios.verizon.net) joined #forth 14:17:54 --- quit: Gromboli (Read error: Connection reset by peer) 14:18:15 --- join: Gromboli (~Gromboli@pool-98-118-174-158.bflony.fios.verizon.net) joined #forth 14:42:33 crc, thanks. Yikes pulls from ZOL ? whats wrong with pulling from Open ZFS ? 14:43:19 --- quit: dys (Ping timeout: 245 seconds) 14:45:12 crc, I don't understand how ZOL even exists considering that the CDDL and GPL are incompatible. Cant the linux people just go and finish their BTRFS and leave Open ZFS alone ? 14:49:52 back 14:50:18 welcome back! 14:50:20 hey tp 14:50:40 hey tabemann how goes the data alignment ? 14:51:10 well it's working now, and it is faster than I thought - the performance issues were mostly that I forgot to compile hashforth with -O2 14:53:07 now I need to figure out something else to do with hashforth 14:53:21 so all your loops are now optimised away ? ;-) 14:53:39 lol 14:54:23 well whatever -O2 does it works and it works better than without it 14:55:34 I should port hashforth to Cortex M, but I don't know whether to port my C implementation or to recode it in ARM or Thumb2 assembly 14:55:55 I love C and it's use of the volatile word. "you must use volatile when anything is changing that the compiler doesn't know about, like the changing of the Queens Guard, or if Winter is changing to Spring" 14:56:00 I've got a Cortex M4 board that's been sitting at my table for months now untouched 14:57:16 'recode' in Assembly ? You mean start from scratch as it's in C atm ? 14:57:38 yeah 14:57:46 it's currently written in C 14:57:51 understand 14:58:35 Assembly will be a huge challenge after C ? 15:00:10 especially Thumb2 Assembly, all those 1024 range limited IMMediate instructions 15:00:43 hashforth runs TTC, so thumb2 code would only pertain to the runtime itself 15:01:01 I love Assembly myself, not particularly Thumb2 Assembly tho 15:02:29 the main thing is that if I were to port hashforth in C to Cortex M, there are parts I would have to write in assembly anyways, namely the interrupt-handling code 15:02:56 Im not a real programmer so I don't know what TTC is, it's obviously "something, something code" ? 15:03:07 token-threaded code 15:03:12 ahh thanks 15:03:50 it's like ITC, indirect-threaded code, but instead of threading addresses it threads tokens that refer to words 15:04:03 because it's written in C ? 15:04:24 nah 15:04:34 because it makes it more portable 15:04:56 because then words don't have to care about their position in memory 15:05:22 more portable to what ? other ARCH types ? 15:06:03 that, or even just different memory layouts on the same arc 15:06:06 *arch 15:06:21 e.g. if there is memory layout randomization 15:07:33 so how much of your TTC will you need to alter for say Thumb2 on Cortex-M0 ? 15:07:54 well Thumb2 runs on all Cortex-M 15:08:32 I will need to regenerate my TTC because I'm gonna change the token size to 16-bit 15:08:42 from 16/32-bit 15:09:13 Moore said " only put in your Forth code what you need right now, not what you may need" but he didnt say if that applied to your Forth also ;-) 15:09:31 also I will be changing things such as my signal/interrupt handling because there will be a different set of interrupts 15:10:24 also the IO will change drastically 15:10:29 I thought that Thumb2 is 16/32 bit with most instructons being 16 bit ? 15:10:47 because my IO currently is POSIX-based 15:10:56 because hashforth targets x86 atm ? 15:11:09 tp: token size doesn't have to do with processor instruction size 15:11:45 apologies, I'm way out of my depth here 15:12:11 I'm a hardware guy 15:12:48 I've learnt a lot just lurking here but I should stay out of the Forth design programming discussions 15:13:02 nah, you're doing fine 15:13:50 so why change your token size ? 15:14:20 well, maybe I'll stick with 16/32 15:14:45 I figured on a small system 32 wouldn't be needed due to the size of the system 15:14:51 so many design options :) 15:15:15 and also 16 is faster than 16/32 because it doesn't need to test for whether 32 is to be used 15:15:27 theres also 8/16 for very small systems 15:15:35 but that again has a performance hit 15:15:50 65536 tokens is enough for anyone, just ask Bill Gates 15:16:25 tabemann, why do you need assembly for interrupts? 15:16:37 like on my DISCOVERY board I might want to use 16/32 because it has a lot of flash space 15:17:19 true, M4 does have a lot of Flash, M0 is limited to 64KB however 15:17:57 MrMobius: can you program for Cortex M so as to handle interrupts in straight C? 15:18:47 tp: yeah, like on M0 I might do 8/16 15:19:07 tabemann, im sure you can. that's a common thing on any other microcontroller 15:19:53 you just have to figure out whatever the compiler's convention is for naming the function that the interrupt calls 15:20:29 and there will be a header of some kind that lets you access interrupt flags 15:20:31 I'll look into it - I just remember there being registers that are saved automatically and registers which the user has to manually save for interruptes on ARM 15:20:54 *interrupts 15:20:59 why does that matter? C is handling all that for you anyway :P 15:21:49 I mean, because the compiler can't just know which functions are interrupt handlers 15:22:39 if there was something like __irq_handler or __fiq_handler that'd make life much simpler 15:26:42 just looked and I didn't use interrupts on my M0 project but I have this for MSP430 stuff for example __attribute__((interrupt(TIMER0_A0_VECTOR))) static void TA0_ISR(void) 15:28:17 tp: as I understand it, the FreeBSd team is working to merge their changes into ZoL as ZoL is better developed in a number af areas 15:28:42 there is a mailing list thread relating to this: https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html 15:29:52 * crc only has one server using zfs, will likely not use it again for a personal server (zfs uses a lot of ram, whickh is very limited an my small servers) 15:30:14 crc, thanks 15:30:43 I use zfs on this workstation and I have become very dependent on zfs now 15:31:13 it was my zfs addiction that stopped me moving to Openbsd at one point 15:31:30 The change is supposed to be forwardly compatible with the ZoL based implementation 15:32:24 My FreeBSD setup w/zfs is still on 11.2 currently 15:33:08 crc it's a massively complex area I know. I was a Linux refugee to FreeBSD initally and I'm just worried about more linux integration 15:33:46 same here, 11.2-p9 15:33:50 I'm msotly using openbsd now 15:34:07 which doesnt have zfs sadly 15:35:22 i *really* liked OpenIndiana and would have moved to that but it seems to be withering away ? 15:35:54 I couldnt find many of the applications I need on OpenIndiana also 15:36:50 I'm still disappointed that SUN had to die 15:36:51 one big part of why I've stuck to Linux is that I get POSIX but also get a lot of applications which are likely to not be as available elsewhere 15:37:31 tabemann, youre a programmer and can adapt, I'm a old guy who doesnt like the rapid change of Linux 15:37:39 I really only use the base install, fossil, nano, and retro for development work. 15:38:02 tp, you also seem to not like C so maybe you should stay away from Linux :) 15:38:12 Linux rules the world now as far as Im concerned, it's for the young and energetic, I just want to make the most of my existing unix skillset 15:38:21 I use Discord and Skype, for instance, proprietary software that probably isn't available on xBSD 15:38:58 MrMobius, I used to use C for all my embedded before I became proficient enough to use Forth. I just dont trust C anymore 15:39:59 tabemann, net-im/purple-discord Discord plugin for libpurple 15:39:59 net-im/rubygem-discordrb-webhooks-blackst0ne Discord API for Ruby 15:40:18 the thing about people who say that C doesn't represent an accurate picture of the architecture of modern processors, though, is that no language we have today does aside from assembly 15:40:24 I have a mac for building iOS apps, but much of that is just UI stuff, the backends of everything I do for personal projects is now C and Forth. For work, there's some Python and JavaScript (sadly...) stuff too. 15:40:49 tabemann, no skype except some text app 15:43:16 MrMobius, I actually liked C for many years tho I'm not a real programmer. I wrote a general purpose memory/chip burner for Linux in 1999 with it and released under the GPL 15:43:59 tp, sounds like a real programmer to me :) 15:44:09 not sure how you made it very far in embedded without volatile though 15:44:10 MrMobius, and I really enjoyed that project. If I was going to write something for the PC again and needed speed, I'd use C without hesitation 15:44:11 * tabemann used to release code in the LGPL but these days uses BSD3 15:44:42 tabemann, yeah I'm a BSD3 license person now as well 15:44:51 tp: you seem to underestimate your own capabilities 15:46:08 MrMobius, I used a small russian made C compiler (linux) for PIC and that didnt even have 'volatile' back in 1998 15:46:36 dear lord 15:46:43 --- quit: dddddd (Remote host closed the connection) 15:46:49 you keep on calling yourself not a programmer etc. but you seem to understand forth much better than when I first decided to write a forth implementation 15:46:52 but it could still optimize out loops? 15:47:14 tabemann, no, I never underestimate myself, Im *really* good at hardware, and I know a few Hackers, Ive watched them work, and they are like programming GHODS to me 15:47:50 MrMobius, I dont think it had any optimisation, or if it did it wasnt that advanced 15:48:10 i guess you wouldnt need volatile in that case 15:48:34 MrMobius, it was just for a PIC 14 series and beat assembly or machine code :) 15:49:15 it also worked well and gear I designed and sold using it is still working in factories to this day 15:49:25 what I mean is you seem to have a better understanding of programming than many people do 15:49:55 most programmers aren't hacking gods 15:50:31 certainly most of those Java and JavaScript developers out there aren't 15:51:10 just the fact that you have programmed for embedded systems using C and Forth says something 15:51:12 Yeah Im sure most programmers aren't hacking gods, but the guys I know can memorise a page of code in about 20 seconds and retype it all from memory 15:51:31 theyr never need to look at reference data, it's all in their heads 15:51:49 heh, I doubt they have a very wide scope then 15:51:54 they know all the commands for VIM Ive never heard off and they type at lightning speed 15:52:14 I don't feel the need to know much of that stuff 15:52:17 that is kind of a common discussion amongst programmers that a lot of them feel bashful admiting they still have to google all kinds of stuff after years or decades of experience 15:52:30 no one has or can have all that memorized unless they are specialized in a very narrow field 15:52:38 like for vim, I know a few commands, and that's it 15:52:49 * crc is no longer able to type quickly :( 15:52:56 even professional code will have links to stackoverflow in the comments. no one expects you to know everything there is to know cold 15:53:03 okay, I have to eat dinner now 15:53:04 bbl 15:53:32 i realised that my need to always have reference books open, my lack of mastery all the VIM commands, and my 20 WPM two finger typing would pretty much disqualify me from ever being a *really good programmer* 15:53:46 no problemo taberman, thanks for the chat :) 15:54:32 MrMobius, true, but having the qualities the Hackers I admire have is a massive advantage 15:55:20 I keep the glossary for my forth system readily available, and I use it literally every day; using reference materials doesn't disqualify one from being a good programmer 15:55:26 is a good programmer, morally good, or just proficient enough to make their actions seem like magick to random on-lookers? 15:55:43 tp, ya but if that is your standard then 99%+ of the people being paid a salary to write programs aren't "real programmers" 15:56:21 --- join: tpbsd (~Terry@mecrisp/staff/tp) joined #forth 15:56:38 Im on their level with electronics and one man cant do *everything* so I'm happy with the state of things 15:56:38 --- quit: tp (Remote host closed the connection) 15:56:53 --- nick: tpbsd -> tp 15:57:52 thanks for the encouragement anyway guys :) 16:00:21 MrMobius, Ive never used stackoverflow for Forth or anything, I do scan it to answer questions if I can 16:00:51 MrMobius, besides, no one has answers for my questions anyway 16:05:40 --- join: john_cephalopoda (~john_ceph@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:31:24 just so you know, lack of mastery of vim and 20 wpm two finger typing do not qualify you from being a really good programmer 16:31:40 but going off to the coffee shop now, bbl 16:32:39 how about lack of serious mental horsepower ? 16:33:27 I have a daughter who is *seriously* smart, but she gets it from her mum :) 16:36:41 --- quit: tabemann (Ping timeout: 276 seconds) 17:23:18 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:26:28 --- join: rdrop-exit (~markwilli@112.201.162.86) joined #forth 17:32:17 Good morning Forthians :) 17:32:52 morning man from the simple life! 17:33:09 Hi tp :) 17:34:13 hey rdrop-exit whats the weather like today ? we have local fires and haze in Northern NSW 17:36:07 8:35am Cloudy but cool, 27C 17:36:17 hey rdrop-exit, tp 17:36:24 hey tabemann 17:36:36 80.6F 17:36:43 hi tabemann 17:37:05 21C here atm 17:37:15 --- quit: karswell (Read error: Connection reset by peer) 17:38:29 I should figure out how to set up a C build environment for Cortex M4 (and for Cortex M0), so I can attempt a minimal-effort port of hashforth (i.e. rip out POSIX, add support for processor interrupts in the place of signals) 17:38:36 expecting a couple thunderstorms/rainstorms today 17:38:53 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 17:39:42 tabemann, dont you just set Gcc to -mthumb2 ? ;-) 17:39:51 lol 17:41:54 What is reelfeel? Accuweather says it will be 29C today, but reelfeel 34C 17:42:20 probably temp plus humidity "feels like" ... 17:42:37 --- join: dave0 (~davezero@069.d.003.ncl.iprimus.net.au) joined #forth 17:42:46 you're likely right 17:43:42 humidity is only 85% atm 17:46:17 21 C 14% RH here, feels cold 17:48:14 bbs 17:49:22 bulletin board system 17:49:27 ;-) 18:04:29 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 18:05:09 don't tell me they actually call it reelfeel... and from checking their site, they do call it RealFeel 18:05:29 so they've trademarked the heat index 18:07:57 You're right it's RealFeel, I should have worn my reading glasses. 18:16:17 I can actually picture some company calling it ReelFeel though 18:17:57 All caught up on clf, checking reddit. 18:18:08 clf? 18:18:18 comp.lang.forth 18:18:23 ah 18:19:04 I'm kind of surprised that adding alignment has had less of a performance hit than I expected 18:19:24 I though it had a major hit, but then I realized I just had forgotten to compile hashforth with -O2 18:19:52 Depends on the platform 18:20:27 well I mean on x86-64 18:20:47 on M0 it wouldn't even run 18:20:53 without alignment 18:22:15 I guess the penalty isn't as high as it used to be on newer chips 18:22:22 Will check Fog 18:23:00 with some decent optimization the alignment operation should actually pretty cheap - a subtraction, an or, and an addition 18:23:25 with each of those operations having a constant argument 18:23:54 --- join: ryke (~Thunderbi@71-9-171-192.dhcp.jcsn.tn.charter.com) joined #forth 18:23:54 furthermore I did some optimization to reduce the number of cases where the alignment operation has to come into play 18:23:55 Oh I thought you meant the cost of an unaligned access 18:24:40 I meant going from my unaligned version of hashforth on x86-64 to an aligned version of hashforth for the same 18:26:25 the big cases where the alignment operation comes into play on hashforth built for 16/32-bit tokens are when doing branches (as branch arguments are 64-bit on systems with 64-bit cells), and 32-bit and 64-bit literals 18:26:55 Aligning of addresses is usually done at compile-time 18:27:10 it tries as much as possible to limit literals to 16 bits, which means no alignment is needed for them (because they're already guaranteed to be aligned) 18:27:56 rdrop-exit: what I mean is that like on a 16/32-bit token setup, a 64-bit branch argument following a 16-bit branch token is almost certainly going to need padding calculated for it 18:28:30 at compile-time though, not at runtime 18:29:01 i.e. when you're laying down the branch 18:29:12 no, no 18:29:38 what I mean is let's say I have a (branch) token followed by a destination 64-bit argument 18:29:46 the destination argument needs to be aligned 18:29:46 ok 18:30:04 but the system needs to calculate how far from the (branch) token 18:30:13 the destination argument is 18:30:27 the actual calculation is very cheap 18:30:41 it's just subtract a constant, or a constant, add a constant 18:31:10 but it's still an (albeit very small) hit, multiplied many, many times 18:32:27 one way of doing it that I thought of was to make separate tokens for each different amount of padding needed 18:32:38 but I figured that'd make things too complex 18:33:28 You want the overhead to be constant at runtime 18:33:38 especially when porting hashforth between sytsems with different cell sizes 18:33:51 the overhead is constant 18:34:34 it should compile down to three instructions with no branches or predication 18:35:25 or five instructions if no immediate arithmetic instructions exist 18:36:14 x86 instructions? 18:37:02 I haven't actually checked the compiler output 18:39:28 right now I'm checking the ARM instructions that this should compile to 18:40:45 damn you ARM Infocenter 18:40:52 lol 18:42:01 when I search for something like "Thumb2 instructions" (minus quotes) and it shows up as the first entry on Google, I would assume that it was going to lead me to what I was looking for! 18:50:17 --- quit: Gromboli (Quit: Leaving) 18:54:02 Your doing a TTC Forth with 16 bit tokens, is that right? 18:54:13 * You're 18:57:44 right now I'm using 16/32-bit tokens 18:58:05 where tokens are 16-bit if they are smaller than or equal to 32767, otherwise they use 32-bit tokens 18:58:24 I could switch it to just 16-bit tokens, as I'm not getting anywhere near 32767 18:58:33 and get a performance boost that way 18:59:19 I need to heard out, though - coffee shop is closing 18:59:20 bbiab 18:59:30 Normally on a TTC all tokens are the same width 19:01:15 I devised this mostly so I could default to 8 bit tokens for frequent words on really constrained systems while still having 16 bit tokens available 19:02:04 I do need to go though 19:04:22 hmmm 19:06:36 --- quit: tabemann (Ping timeout: 258 seconds) 19:07:05 So you have an "escape" opcode, I see 19:10:38 Ah from you're description above, you're not using an escape opcode. Hmmm 19:12:36 An escape bit 19:20:39 Why would you ever need 32-bit tokens in a TTC, sounds like overkill 19:22:38 just in case 19:24:19 in case you need more than 64,536 different words? =:-O 19:24:48 * 65,536 19:25:58 Hold, will dig up a description of a typical TTC Forth... 19:26:50 Here we go, classic description from Bard Rodriguez: 19:26:52 https://www.bradrodriguez.com/papers/moving1.htm 19:27:09 * Brad Rodriguez 19:27:51 TTC is described towards the middle 19:29:52 no, in case you need 4 billion words 19:32:26 7 billion people 19:35:28 I assume when tabemann uses the word "token" he's including the width of any immediate data that may follow the token. 19:36:46 Perhaps 19:37:28 --- quit: dave0 (Quit: dave's not here) 19:39:57 His token is more like an instruction, while the traditional token is more like an opcode. 19:49:35 --- join: tabemann (~tabemann@2600:1700:7990:24e0:d52f:9716:32ef:4941) joined #forth 20:13:34 --- quit: dbucklin (Quit: WeeChat 2.3) 20:26:26 bbl 20:26:30 --- quit: rdrop-exit (Quit: Lost terminal) 21:07:28 --- quit: karswell (Read error: Connection reset by peer) 21:09:08 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 21:13:41 --- quit: karswell (Ping timeout: 246 seconds) 21:23:22 --- join: gravicappa (~gravicapp@h109-187-24-48.dyn.bashtel.ru) joined #forth 21:26:43 * tp is happy, I finally cracked the correct syntax to use Screen (serial terminal) to parse the mcu Forth compiler error messages thru Sed so as to ring the PC bell when they occur :) 21:28:05 I now have colour syntax error highlighting in the terminal, a pc bell on the errors, and even the ability to freeze the source upload to the MCu at the error if I want 21:29:00 I don't think there is much else I want by way Forth on chip compiler error detection 22:37:41 --- join: proteusguy (~proteusgu@180.183.129.114) joined #forth 22:37:42 --- mode: ChanServ set +v proteusguy 23:24:34 --- join: nullnullnull (~nullnulln@31.154.190.34) joined #forth 23:34:03 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 23:59:59 --- log: ended forth/19.09.08