00:00:00 --- log: started forth/21.03.31 00:02:06 --- join: f-a joined #forth 00:06:36 --- join: gravicappa joined #forth 00:40:53 --- quit: dave0 (Quit: dave's not here) 01:06:58 --- quit: gravicappa (Ping timeout: 252 seconds) 01:11:51 --- join: gravicappa joined #forth 01:36:23 tabemann: Rather than optimise constants I just do e.g. "[ 2 CELLS 1+ ] LITERAL" everywhere 01:36:37 Although I don't need to do it much 01:37:05 I like having a language where you can tell the compiler to calculate a constant at compile-time 01:47:46 dave0, KipIngram: https://crypto.stanford.edu/~blynn/rop/ 02:26:26 --- quit: f-a (Quit: leaving) 02:27:45 Ah, interesting. Thanks. 02:28:29 I'd never been exposed to the idea before I had dave0 describe his system, which basically uses "return" as the inner interpreter (so it's direct threaded). I thought it was a novel idea and was really interested in seeing how it panned out. 02:29:38 I thought there might be a problem with interrupts corrupting his definition space (since it's his processor stack) but it turns out that interrupts use a whole different stack space. 02:30:00 So as long as *he* didn't screw up his space, he should have been ok. 02:30:21 I would have stolen that trick if I did direct threaded systems. 02:30:26 But I usually go indirect. 02:43:34 mark4's x64 does this too, don't know about x4 though 02:43:46 i.e. uses ret as next 02:51:11 --- join: f-a joined #forth 02:52:29 I wanted to put machine code and Forth "code" in the same section. I can't do that with the segments granted me by the system when the program first loads. 02:53:12 So, I allocate two regions of RAM, one for code and parameter space, and the other for name strings, links, and CFA/PFA pointer pairs. 02:53:26 My system doesn't have the CFA "just before" the content of a word. 02:53:43 There is the CFA pointer to some code, and then a PFA *pointer* to the parameter space. 02:54:01 Primary reason for doing that was so that I can have multiple entry points to a definition - I can do this: 02:54:15 : foo ... ... : bar ... ... ; 02:54:32 And nothing that happens when I add bar to the dictionary pollutes the definition sequence. 02:54:41 All those ... pieces are contiguous. 02:57:15 So anyway, I create the initial content of those regions in my assembly .text and .data sections, and then at startup I copy those regions into the two allocated regions. It's all relocatable anyway - all of my cells contain offsets from the start of the region, and I use registers r15 and r14 to point to the regions. 02:57:34 So my code adds r15 or r14 to each scooped up value appropriately. 02:57:56 So when I jump to that I no longer have any permission limitations on what I can do with the memory. 02:58:11 I allocate the regions read/write/execute. 02:58:38 COLD will jump back down to the initially loaded code and re-copy the sections, using the same memory regions as before. 02:59:08 It took a bit of diddling to get that to work. 03:01:31 And at least the .text section is write protected, so there's some protection from corrupting the initial image. 03:03:51 "There are, however, some architectures and/or operating systems that forbid a program to generate and execute code at runtime. We consider this restriction arbitrary and consider it poor hardware or software design. Implementations of programming languages such as FORTH, Lisp, or Smalltalk can benefit significantly from the ability to generate or modify code quickly at runtime. 03:03:54 " 03:04:01 Ooops - sorry. 03:16:10 --- quit: f-a (Quit: leaving) 03:58:24 --- join: dave0 joined #forth 03:59:00 maw 04:15:42 --- join: tech_exorcist joined #forth 04:39:09 Morning. 05:15:48 --- quit: gravicappa (Ping timeout: 240 seconds) 05:18:35 dave0: Did you see the link siraben posted for us? 05:18:40 More on ROP. 05:19:04 KipIngram: Ben Lynn's website is a gold mine for CS stuff, really smart guy 05:19:10 KipIngram: ah nope, have you still got it? 05:19:20 hi siraben 05:19:21 admittedly some parts of 05:19:23 https://crypto.stanford.edu/~blynn/rop/ 05:19:24 https://crypto.stanford.edu/~blynn/rop/ 05:19:31 are a bit beyond me, but it's neat nonetheless 05:19:32 I'll have to check him out. 05:19:42 That one was really interesting. 05:20:23 KipIngram: my favorite is his compiler series: https://crypto.stanford.edu/~blynn/compiler/ 05:20:37 And I agree with his conclusion that execution protection is a futile gesture that just complicates life for some people (like Forth developers) without really securing the landscape. 05:20:37 the RTS is a single file ANSI C program 05:20:44 Right. 05:20:56 it's really annoying to do some stack related things on modern systems 05:21:37 Well, just the notion of wanting an assembler and to create new code words is ruled out from the jump. 05:21:40 i recognize this page 05:22:30 --- join: gravicappa joined #forth 05:22:40 I just completely bypassed all that by copying my system off to newly allocated blocks that are wide open permission-wise. 05:22:48 Never mind that block I got loaded in. 05:23:11 KipIngram: i think it's lucky that there is JIT things like the java runtime thing, so hopefully it will always be possible to enable writing code on the fly and executing it 05:23:25 javascript JIT too 05:23:39 Yeah. 05:24:05 Well, it has to be *possible*, from a hardwre perspective, because the system needs to load programs. 05:24:21 oh yeah didn't think of that! 05:24:39 You ever hear of capabilities? I ran across htem decades ago, and they seemed like a good way to manage access. 05:25:33 Basically it's a setup where items that can serve as addresses have some special bits set, that you yourself can't just "set." They're set by the privileged part of the system. 05:25:45 So you can't just make up a pointer and access any part of memory. 05:25:52 You have to have a "capability" for it. 05:26:05 And there are rules around creating, copying, and sharing capabiliies. 05:27:18 So I might have read/write access to some memory range, and I could share a capability with you that only provided read access. 05:27:47 The permision bits are actually "in the computer word," and are managed by secure hardware. 05:35:18 KipIngram: oh wow, that's crazy 05:35:40 the TI-84+ has a sorta similar restriction, the first page of RAM is read-only 05:35:47 (Z80) 05:37:59 Speaking of JIT, are there some Forth implementations affected by this Apple Silicon (M1 chip) security limitation that's affecting MIT Scheme ? 05:38:03 "No support for Apple silicon: At this time, we are unable to support new macs using Apple's silicon (the M1 chip). Although we support the ARM architecture it's based on, Apple's design uses W^X restrictions that conflict with the way that MIT/GNU Scheme manages memory." 05:38:14 "Our native-code implementation requires both write and execute permissions on memory, and fixing that is a significant redesign that's unlikely to happen in the near future." 05:39:50 --- join: f-a joined #forth 05:42:21 X-Scale, probably a forth written for a Harvard architecture could port to the M1. But I wonder how much other undocumented proprietary nonsense is in those machines... 05:44:00 i think indirect threading would work 05:44:38 it's amazing how forth can adapt to those things 05:48:46 X-Scale: oof, didn't know MIT Scheme didn't run on M1 05:48:47 proteus-guy: indeed. Digital jails implemented in hardware. It's a dangerous trend. 05:51:24 siraben: it's stated on the front page: https://www.gnu.org/software/mit-scheme/ 05:51:50 ever since T2 was introduced, Linux on Mac has been a pipe dream 05:52:00 technically yes you can boot a distro on it, but good luck getting all the hardware to work 05:53:20 It's kind of an interesting limitation, I don't know about MIT/GNU Scheme but Forths can certainly be written to work around this without any particular penalty 05:53:23 Just a bit more work 05:55:03 https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon 05:55:58 Forget about self-modifying code 05:59:39 --- quit: gravicappa (Ping timeout: 260 seconds) 06:01:10 all these hardware mitigation things because of a bogus language C where the real problem is 06:01:40 --- quit: f-a (Quit: leaving) 06:01:48 X-Scale: The permissions are per-thread 06:02:20 You could have a thread for dispatching modifications to the dictionary 06:02:42 "avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region." 06:02:46 broken by design lol 06:03:21 I'm sure there are other work-arounds 06:04:25 Yeah, sounds like Apple's going whole hog down the wrong road. 06:05:11 dave0: Yes, you could still put a Forth system together. You just wouldn't be able to easily create new primitives. 06:06:02 veltas: Ah, ok, that is better. You don't really need to write annd execute so close together that different threads couldn't handle it. 06:06:27 Might also be an mmap solution, map two different address ranges to one block of memory, have different permissions on those ranges 06:07:05 I worked around it as I indicated earlier. The main difficulty was getting some of the initial variable contents set, because the actual value of a variable lives in the section that was .text at startup. Writing not allowed. 06:07:16 Would not be shocked if enough stuff stops working they just roll it back and allow RWX in future 06:07:27 So I had to copy the images to their new home and then set the values there. 06:08:08 It's just bizarre that they cling so hard to these policies when they don't really represent a significant barrier to hacking. 06:08:23 That paper siraben posted earlier explains how easy it is to defeat. 06:08:57 By default code is read-only, and any JIT code will still be modified, albeit with more effort, so is still 'hackable' in mostly the same way 06:09:12 I have an example of similar stature with my employer. The decided to switch off the ability to write to USB drives on our computers. 06:09:17 We can still read them, but can't write. 06:09:34 And that means you can't work with any kind of a dev kit, can't manage books on ereaders or songs on iPods, and so on. 06:09:55 The stated reason for this was to prevent employees from writing important IP to portable drives and walking out with it. 06:09:58 But guess what/ 06:10:00 ? 06:10:05 That was my guess 06:10:12 Burning DVD plugged in to the USB port still works. 06:10:24 So, they accomplished NOTHING. 06:10:33 That's a harder though, and makes noise 06:10:33 Except to make using the computer for side purposes impossible. 06:10:48 You can probably SFTP stuff without them having any idea too 06:10:57 Yes. 06:11:08 We can still scp, sftp, use Dropbox, etc. etc. 06:11:26 So it was just done so that some executive could tell his boss that "proactive steps had been taken." 06:11:29 A lot of security policies are like this, break stuff and don't actually secure anything 06:11:30 Stupid corporate thing. 06:11:36 Right. 06:11:40 It's mostly for show. 06:12:14 I was really hacked when I realized I couldn't manage my ereader books anymore. 06:12:30 I mean, obviously that's a personal use. 06:12:40 But it's the kind of personal use that most employers don't mind. 06:12:45 Long as it's on your own time. 06:12:56 What it does is raise the chances of me buying my own computer. 06:13:11 Then I won't have my work computer in front of me as much, and I'll wind up doing less work. 06:13:25 I found a way to work around on the ereader. 06:13:52 I use the Calibre program to manage my library on the computer, and it has a feature called a "content server." You turn that on, and it creates a WiFi accessible website. 06:14:06 I can hit that with the ereader's browser and download books that way. 06:14:21 Which is the only truly essential capability. 06:15:17 But I really wish I had a good way to dick around with little development kits of various kinds. 06:15:27 Of course, a lot of those require Windows. 06:15:35 Which is just never going to happen again, in my life. 06:15:55 I get really agitated with vendors who only support Windows use of their products. 06:16:41 My work computer is MacOS, and it's... "ok." 06:16:49 It behaves enough like Linux that I can deal with it. 06:17:13 But I had to jump through some extra hoops to make this Forth work on it. 06:17:34 You can't really use absolute addresses of any kind in a MACH-O executable. 06:17:44 Everything has to be relative. 06:17:54 So a Forth definition as a list of addresses? No go. 06:18:05 So mine are lists of offsets, from the base address of the system. 06:18:20 I keep that address in a register, and NEXT is the first thing, it's AT that address. 06:18:27 So NEXT just becomes jmp r15. 06:19:14 (:) loads the contents of each word's CFA and then adds r15, and jumps there. 06:19:17 Etc. 06:19:47 Addresses on the stack are real addresses - it's easy enough to use absolute addresses "one level up." 06:19:58 But that bottom foundation layer has to do all this offset trickery. 06:21:01 My C Forth is trying to avoid so much trickery, but I am mapping to a fixed address to achieve that which has its own issues 06:25:57 Once I get it so it can rebuild itself, I could probably rebuild an absolute image. 06:26:08 I'll see if I can keep that an easily available option. 06:26:24 veltas: My, uh, "Forth before last" was a gcc version. 06:26:36 The source code was ungodly ugly. 06:26:41 But it worked. 06:27:38 The source for the last one (nasm assembly) was much cleaner, and this time it's cleaner still. I got some really nice macros put together that construct the dictionary and so forth. 06:31:40 --- quit: cp- (Quit: Disappeared in a puff of smoke) 06:43:52 --- join: f-a joined #forth 06:52:32 --- join: gravicappa joined #forth 07:23:20 veltas: are you using gcc for your Forth? 07:49:16 KipIngram: It uses GCC but not GCC specific features 07:49:23 I am using GCC to compile anyway 07:49:48 Well apart from being able to use a function pointer like a pointer, but all C compilers let you do that 07:49:51 I see. You aren't using gcc's pointer to label extension for your inner interpreter? 07:49:54 No 07:50:10 Ok. I used that in mine, so I had a really standard inner interpreter. 07:50:42 I'm trying to keep it somewhat simple, it's a tokenised representation because I don't want dictionary to be unnecessarily huge 07:51:02 I can add you to repo after work if you're interested in seeing what it looks like 07:51:18 Nothing works right now, early days 07:51:24 Oh, sure - I always like seeing what other folks are up to in Forth. 07:51:30 Me too 07:52:19 The idea is the file will build two different binaries, one to build the core dictionary, and a lighter one that loads the dictionary as a precompiled image 07:52:42 based on whether PREBUILD or whatever I called it is defined 08:01:59 --- quit: dave0 (Quit: dave's not here) 08:53:34 --- join: cp- joined #forth 09:00:42 --- quit: tech_exorcist (Remote host closed the connection) 09:01:10 --- join: tech_exorcist joined #forth 09:55:19 KipIngram: Is this you? https://github.com/KipIngram 09:55:40 Yes, that would be me. :-) 09:56:14 There are other Kip Ingrams around, but none of them seem to be in tech. 09:56:32 There's a fireman somewhere, and a preacher somewhere, and one other one I ran across once. 09:58:35 I have invited you to the repo whatever that means 09:58:56 It's not particularly secret, I just don't want to make it totally public until it's a bit more complete than it is right now 10:06:22 Totally understand. 10:44:26 --- quit: f-a (Read error: Connection reset by peer) 10:47:28 --- quit: gravicappa (Ping timeout: 240 seconds) 10:48:21 --- join: gravicappa joined #forth 10:48:31 --- join: f-a joined #forth 11:17:53 veltas yea i dont like making a repo public till its not embarrasing :) 11:23:30 --- quit: jedb_ (Remote host closed the connection) 11:24:22 Exactly 11:27:32 Or in my case, less embarrasing 12:08:58 Linux would never have become popular (or useful) if people didn't jump and help improve Torvald's original messy and incomplete code :) 12:37:09 Test, am I still connected? 12:37:13 Yes I am. 12:42:08 neuro_sys: no, it is a phantom signal you are getting 12:45:23 Dammit 13:10:33 --- quit: gravicappa (Ping timeout: 240 seconds) 13:59:08 --- quit: f-a (Quit: leaving) 14:03:10 :-) 15:23:39 --- quit: MrMobius (Ping timeout: 268 seconds) 15:24:57 --- join: dave0 joined #forth 15:25:23 maw 15:30:37 --- join: MrMobius joined #forth 15:57:01 --- quit: tech_exorcist (Remote host closed the connection) 15:57:17 --- join: tech_exorcist joined #forth 16:14:02 --- join: jedb joined #forth 16:19:03 Hey hey hey. 16:22:00 Well, I guess I'll start ticking this FIND stuff in. I've cogitated on it for a good while; gotta do it sometime. 16:23:04 I added words PATH and FORTH earlier, and have it so on startup PATH will point to FORTH and FORTH's links are null. And FORTH properly points to the linked list. 17:16:12 --- quit: dave0 (Quit: dave's not here) 17:37:12 --- quit: tech_exorcist (Quit: tech_exorcist) 17:56:49 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 18:02:30 --- join: Lord_Nightmare joined #forth 18:21:25 back 18:21:50 KipIngram: the name "zeptoforth" comes from the SI prefix "zepto" plus "forth", which I chose because the name wasn't taken yet 18:25:03 I see. 18:26:36 the irony is that zeptoforth is not a small forth 18:26:36 --- quit: tabemann (Remote host closed the connection) 18:26:52 --- join: tabemann joined #forth 18:27:08 Yeah, I was trying to remember which end zepto was on. 18:27:18 I take it it must be on the small end. 18:27:29 yeah, "zepto" anything is really small 18:45:58 --- join: boru` joined #forth 18:46:00 --- quit: boru (Disconnected by services) 18:46:03 --- nick: boru` -> boru 18:46:13 Heh; except Forth. :-) 19:41:20 --- quit: X-Scale (Ping timeout: 240 seconds) 19:55:37 --- join: X-Scale joined #forth 20:00:42 --- join: dave0 joined #forth 20:03:35 maw 21:34:03 --- quit: xek (Remote host closed the connection) 22:47:12 --- join: gravicappa joined #forth 23:33:55 --- quit: proteus-guy (Remote host closed the connection) 23:35:20 --- join: proteus-guy joined #forth 23:55:00 --- join: f-a joined #forth 23:59:59 --- log: ended forth/21.03.31