00:00:00 --- log: started forth/19.07.13
00:14:56 --- join: dys (~dys@tmo-100-93.customers.d1-online.com) joined #forth
00:47:12 --- join: john_metcalf (~digital_w@host31-54-142-171.range31-54.btcentralplus.com) joined #forth
00:47:18 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth
00:47:54 <dave0> hi
00:48:11 <tp> g'day dave0 
00:50:15 <dave0> hi tp
02:18:24 --- join: xek (~xek@apn-31-0-23-202.dynamic.gprs.plus.pl) joined #forth
03:08:53 --- quit: john_metcalf (Ping timeout: 268 seconds)
04:11:47 --- quit: jedb (Ping timeout: 246 seconds)
04:13:46 --- join: jedb (~jedb@103.254.153.113) joined #forth
04:34:59 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:50:24 --- quit: jedb (Ping timeout: 245 seconds)
04:52:06 --- join: jedb (~jedb@103.254.153.113) joined #forth
06:20:35 --- quit: X-Scale (Quit:  HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC)
07:51:34 --- quit: dave0 (Quit: dave's not here)
08:13:04 --- quit: clog (^C)
08:13:04 --- log: stopped forth/19.07.13
08:17:35 --- log: started forth/19.07.13
08:17:35 --- join: clog (~nef@bespin.org) joined #forth
08:17:35 --- 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'
08:17:35 --- topic: set by proteusguy!~proteusgu@cm-58-10-209-120.revip7.asianet.co.th on [Wed Jun 26 09:13:14 2019]
08:17:35 --- names: list (clog andrei-n jedb dddddd xek dys reepca gravicappa Zarutian tabemann djinni john_cephalopoda irsol cp dave9 MrMobius kori pareidolia deesix rpcope nonlinear chunkypuffs Keshl ovf arrdem__ mstevens a3f amuck rprimus cheater jimt[m] bb010g siraben tp remexre dbucklin sigjuice cantstanya dne +proteusdude +KipIngram lonjil koisoke +crc APic lchvdlch alex4nder catern pointfree the_cuckoo jn__ gaze__ jpsamaroo presiden dzho phadthai zy]x[yz WilhelmVonWeiner)
08:17:35 --- names: list (yunfan Lord_Nightmare DKordic jackdaniel ullbeking bluekelp rann jhei diginet2 gabc malyn C-Keen Kumool ttmrichter)
08:54:41 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth
08:54:41 --- mode: ChanServ set +v proteusguy
10:01:20 --- quit: proteusguy (Remote host closed the connection)
10:11:39 --- quit: dys (Ping timeout: 245 seconds)
12:03:00 --- join: dys (~dys@tmo-082-183.customers.d1-online.com) joined #forth
12:49:59 --- quit: gravicappa (Ping timeout: 245 seconds)
12:55:43 --- join: gravicappa (~gravicapp@h109-187-229-72.dyn.bashtel.ru) joined #forth
14:07:08 --- quit: gravicappa (Ping timeout: 246 seconds)
14:11:02 --- quit: tabemann (Ping timeout: 276 seconds)
14:26:40 --- quit: andrei-n (Remote host closed the connection)
14:30:55 --- quit: jedb (Ping timeout: 268 seconds)
14:31:55 --- join: jedb (~jedb@103.254.153.113) joined #forth
15:14:54 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
15:16:29 --- quit: Zarutian (Read error: Connection reset by peer)
15:16:46 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
15:23:53 --- part: tabemann left #forth
15:41:59 --- quit: jedb (Ping timeout: 246 seconds)
15:44:05 --- join: jedb (~jedb@103.254.153.113) joined #forth
15:49:59 --- quit: jedb (Ping timeout: 245 seconds)
15:51:25 --- join: jedb (~jedb@103.254.153.113) joined #forth
16:08:13 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:21:52 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:31:15 --- quit: jedb (Ping timeout: 245 seconds)
16:33:00 --- join: jedb (~jedb@103.254.153.113) joined #forth
16:34:33 --- join: X-Scale (~ARM@64.251.28.37.rev.vodafone.pt) joined #forth
16:46:26 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
17:10:31 --- quit: tabemann (Read error: Connection reset by peer)
17:11:38 --- join: tabemann (~tabemann@rrcs-98-100-171-35.central.biz.rr.com) joined #forth
17:28:29 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth
17:59:02 --- quit: tabemann (Ping timeout: 258 seconds)
18:13:24 --- join: tabemann (~tabemann@2600:1700:7990:24e0:3163:3257:92d5:a5e2) joined #forth
20:23:16 --- quit: dddddd (Remote host closed the connection)
20:30:31 <KipIngram> Evening, gents (and ladies, if we have any).
20:31:28 <KipIngram> Just watched the 2000 movie "Frequency" with one of my daughters.  Not time travel, but "time comm" flick, with the usual gaping logical holes that come with "time" stories.
20:31:31 <KipIngram> But it's entertaining.
20:33:28 <KipIngram> The main (repeated) problem is that they'd change the timeline, but keep selected features of the old one, or postpone the effects of past events to the future.
20:34:15 <tp> I find at 65 that it's getting harder to suspend my disbelief for crappy scifi films
20:34:23 <KipIngram> Also one character seemed to have memories of all the timelines.
20:34:26 <tp> ... grumpy old man
20:34:26 <KipIngram> Yes.
20:34:33 <KipIngram> I'm just 56, but I feel that coming on.
20:34:39 <tp> hahah
20:35:02 <tp> i feel that any holes in films are a sure sign of slack work
20:35:23 <KipIngram> Yeah, I tend to agree, though I also see that time stories are... *hard*.
20:35:52 <KipIngram> And they can be entertaining even when they're broken.  Back To The Future had holes in it you could sail a battleship through.
20:35:54 <tp> even worse is the film maker may feel we are too dumb to even notice the holes
20:35:57 <KipIngram> But it was still just a lot of fun.
20:36:24 <KipIngram> I think they feel that 99.9% of their audience won't notice, and they basically say "Fuck you" to the 0.1%.
20:36:33 <tp> i remember that film, I thought it was average 19 years ago
20:36:51 <KipIngram> They've remade it, it turns out.
20:37:04 <KipIngram> Extremely similar plot, but will a female protagonist.
20:37:10 <KipIngram> Ham radio and everything.
20:37:23 <tp> it's a sad comment on human intelligence if 99% won't notice the holes ?
20:37:24 <KipIngram> A friend I chat with here on IRC brought that to my attention a few weeks ago.
20:37:36 <KipIngram> Indeed.
20:38:33 <KipIngram> Here's the bottom line on time travel stories.  If you want to have multiple histories, then you have multiple timelines.  You aren't "fixing" anything when you go back in time and change something.  You're just putting *yourself* into a different timeline.
20:38:42 <KipIngram> All the people you left behind are still suffering whatever it was you set out to change.
20:39:32 <KipIngram> And if there's only one timeline... well, that's boring - you can't change anything.
20:39:39 <tp> time paradoxes are brain burning
20:39:48 <KipIngram> All that can happen is that it can turn out you coming back from the future and doing stuff was part of things all along.
20:40:00 <KipIngram> That's because they don't really make any sense.
20:41:57 <tp> yes, but good scifi makes it all too complex to bother to try and figure out :)
20:48:18 <KipIngram> Yeah.  You can give yourself an aneurysm trying to figure out "Primer."
20:57:54 <tabemann> hey guys
20:58:02 <tabemann> I'm kinda annoyed about something
20:58:11 <tabemann> I want hashforth to port to Cortex M0
20:58:21 <tabemann> but from talking to Matthias Koch
20:58:39 <tabemann> apparently the Cortex M0 has rather severe restrictions on alignment
20:59:00 <tabemann> so I'd have to completely add alignment to hashforth
20:59:11 <tabemann> before I could port it to the Cortex M0
20:59:37 <reepca> I bet it only accepts Lawful Good programs. What a square.
21:00:54 <tabemann> this almost makes me want to just support Cortex M3/M4, as they are not nearly so restrictive
21:01:50 <tabemann> the thing is also I have a Cortex M4 board whereas I do not have a Cortex M0 board
21:02:09 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth
21:02:16 <tabemann> hey rdrop-exit
21:02:26 <rdrop-exit> Hi tabemann
21:02:35 <tabemann> I was mentioning it a moment ago, but I talked to Matthias Koch
21:02:56 <tabemann> apparently he recommends that I get a Cortex M0 board and target that
21:03:18 <tabemann> because apparently Cortex M0 is far more restrictive alignment-wise than Cortex M3/M4
21:03:54 <tabemann> the problem is that hashforth as written basically ignores alignment
21:04:08 <tabemann> so I would have to change a lot of things to get it to work on Cortex M0
21:05:56 <rdrop-exit> Yes, IIRC you decided against the portable VM approach
21:06:48 <tabemann> the VM should be pretty easy to port to Cortex M3/M4 as they do not really impose alignment issues
21:08:07 <tabemann> (I'm planning on still writing the port in assembly using a ARM assembler written in Forth just so I can avoid setting up a gcc cross-compiling environment, but the port itself shouldn't be too hard for M3/M4)
21:09:44 <tabemann> the main non-portable things are that all the POSIX interface code wouldn't be there, the interrupt mechanism would be tied to ARM processor exceptions rather than signals, and I change how compilation works to support compiling to both RAM and to flash, but these are all not big issues)
21:12:33 <rdrop-exit> My understanding of your original intent binary portability
21:12:57 <rdrop-exit> * was binary image portability of the user's programs
21:14:05 <rdrop-exit> with platform-specific extensions available through the SYS opcode
21:15:49 <tabemann> purely from a VM code perspective, yes, even though the VM code would have to take into account the target's characteristics, such as whether there is one big RAM space or whether there is a little RAM space and a medium sized flash space
21:16:39 <tabemann> from this view I might just have to abandon the idea of supporting the M0, because it breaks the idea of VM code compatibility through imposing severe alignment restrictions
21:17:38 <tabemann> I could make changes, which would be significant, in order to support the M0; this code though would be compatible in the opposite direction
21:17:57 <tabemann> such as using NOPs to enforce alignment upon data fields in code
21:18:01 <rdrop-exit> It's not the only target that has alignment restrictions
21:19:02 <tabemann> so for the sake of universality I might as well make changes to make alignment work in general
21:21:55 <tabemann> there are essentially two area where major changes will be needed
21:22:20 <tabemann> first, for starters, I will need to add nops to code to pad data fields into alignment
21:22:46 <tabemann> and also in the general codebase, I will need to make sure alignment is done everywhere
21:23:03 <tabemann> the first is going to be a pain, but it is self-contained, and once its done it is done
21:23:15 --- join: gravicappa (~gravicapp@h109-187-229-72.dyn.bashtel.ru) joined #forth
21:23:27 <tabemann> the latter is more of an issue because it will affect the entire codebase
21:24:08 <rdrop-exit> You need to pin down what you mean by portability for user programs, IIRC it's no longer JVM style portability.
21:25:07 <tabemann> yes
21:25:15 <tabemann> this is not like JVM style portability
21:25:23 <rdrop-exit> What is it then?
21:25:27 <tabemann> because user programs have direct access to the processor's address space
21:26:13 <tabemann> so a user program can be portable or non-portable dependent upon whether it, as written, accesses memory in an aligned fashion or not
21:26:33 <tabemann> whereas the JVM abstracts this away
21:26:59 <tabemann> there is a solution, a major one, but one that would work
21:27:12 <rdrop-exit> So you're going after GForth style portability?
21:27:14 <tabemann> get rid of all non-cell memory access
21:28:04 <tabemann> seems like there isn't any choice if the application is allowed byte-addressed memory access
21:28:46 <rdrop-exit> Portability is a bitch
21:28:53 <tabemann> there is an advantage to forbidding non-cell memory access
21:29:01 <tabemann> then endianness becomes moot
21:30:12 <tabemann> little endian and big endian can be equally fast then
21:30:13 <rdrop-exit> Wasteful for string handling
21:30:20 <tabemann> yes, that's the problem
21:30:27 <tabemann> it's extremely wasteful for string handling
21:30:31 <tabemann> especially on 64-bit
21:31:12 <tabemann> and even for code it's very wasteful
21:31:55 <tabemann> on small systems, for instance, with my current implementation code is composed of 8/16-bit tokens, with all the builtin words that aren't services being 8-bit
21:32:04 <tabemann> which is highly efficient
21:32:14 <tabemann> whereas on small ARM systems like Cortex M
21:32:20 <tabemann> the cell size would be 32-bit
21:32:41 <tabemann> devoting 32 bits to each token is horrifically wasteful considering just how little RAM those systems have
21:33:30 <tabemann> this is why I want to have byte addressing
21:41:28 <rdrop-exit> You need to decide what you mean by portability, since if I've understood correctly hashforth's portability is its differentiating feature
21:42:12 <tabemann> the biggest issue is big systems versus little systems versus very little systems
21:42:21 <tabemann> portability between big systems is not an issue
21:42:40 <tabemann> I could port hashforth in its current form to Cortex A with little more than a recompile
21:43:22 <tabemann> porting to Cortex M3/M4 is going to be harder, because taking compiling to RAM versus compiling to flash into account will complicate things, but all in all it shouldn't be that hard
21:43:32 <tabemann> porting to Cortex M0 will be hard
21:43:47 <rdrop-exit> Don't forget 8 and 16-bit systems :)
21:46:08 <rdrop-exit> or maybe just 16-bits
21:46:34 <tabemann> for very small 32-bit systems like the M0, and for 8-bit and 16-bit systems the VM could be ported, but the whole "userspace" would probably have to be scrapped
21:48:07 <tabemann> so in essence there may be binary compatibility at the image level, strictly speaking, but the system will be so small that the current hashforth "userspace" (which currently has > 1000 words) would have to be replaced with a much smaller one
21:49:16 <rdrop-exit> IIRC what you call "userspace" is what in Forth parlance is traditionaly called the dictionary?
21:49:21 <tabemann> big Cortex M3/M4 systems could probably have a core of the current hashforth "userspace", with the extra stuff such as the line editor removed
21:49:33 <tabemann> rdrop-exit: I mean all the code that exists outside the VM
21:50:25 <tabemann> the code that makes hashforth recognizably a Forth and not just a stack oriented VM which could run some other language
21:55:45 <rdrop-exit> bbiab
22:01:21 <rdrop-exit> back
22:04:01 <tabemann> wb
22:04:08 <rdrop-exit> thanks
22:05:54 <rdrop-exit> So that's the portable part, the VM
22:07:09 <tabemann> yes
22:07:33 <rdrop-exit> or more precisely, it's the runtime that runs portable images?
22:07:43 <tabemann> tes
22:07:45 <tabemann> yes
22:08:35 <tabemann> the VM itself is not fully portable, because when running on bare metal it will have to deal with stuff like processor exceptions that would be platform-specific
22:08:55 <tabemann> e.g. when porting to Cortex M I would have to write at least part of it in ARM assembly
22:11:02 <rdrop-exit> That's the problem of the person porting your VM to a new platform, not the user of the VM
22:11:36 <tabemann> yes
22:14:43 --- quit: dys (Ping timeout: 258 seconds)
22:15:32 <rdrop-exit> So in summary, you have a runtime that will run portable images, anything platform-specific is dealt with via your SYS opcode(s)?
22:16:16 <tabemann> yes
22:16:48 <rdrop-exit> Ok, your "userspace" stuff doesn't really matter
22:18:03 <tabemann> it matters in that it is what makes it actually Forth, just like how JVM bytecode isn't Java by itself
22:18:03 <rdrop-exit> It can be either ignored by the user, or preloaded as part of his image if he needs it and the platform has the resources
22:18:19 <tabemann> but yeah
22:18:31 <tabemann> you could write a compiler for a different language that targets the VM
22:19:03 <rdrop-exit> Or I could have my Forth produce an image for your target, just like any other target
22:19:29 <tabemann> yes, and I very well may do that
22:19:38 <tabemann> because it will enable targeting far smaller targets
22:19:56 <tabemann> than involving the current hashforth "userspace"
22:20:33 <rdrop-exit> That's would be my interest in hashforth, just the runtime, as one possible target for my Forth
22:21:05 <tabemann> okay, bbiab
22:22:15 <rdrop-exit> ok
22:32:44 <tabemann> back
22:33:24 <rdrop-exit> wb
22:48:52 --- quit: dave0 (Quit: dave's not here)
23:18:49 <tp> tabemann, I just read the backchat. Ive only used Mecrisp-Stellaris for cortex-M0, in fact Mecrisp-Stellaris is the only OSS Forth for M0 that I know of
23:19:28 <tp> there are some other Forths that do M3+ but M0 is very rare
23:19:40 <tp> I guess thats because of the alignment issues ?
23:25:43 --- quit: Zarutian (Remote host closed the connection)
23:38:35 <tabemann> back
23:39:10 <tabemann> yeah, I checked the docs, and M0 simply does not allow unaligned access at all
23:54:24 <tp> from a Forth user POV it's never bothered me ;-)
23:59:59 --- log: ended forth/19.07.13