2024-07-15 11:40:04 <darkling    > Is there a reasonably portable method of determining the current number of cells on the stack? (And on the FP stack)? I've had a couple of bugs in my code where I've left extra crud on the stack, and I'd like to write tests to ensure that I'm not leaving extra stuff behind.
2024-07-15 11:44:05 <dave0       > DEPTH .
2024-07-15 11:48:25 <darkling    > Thank you.
2024-07-15 11:49:29 <dave0       > no worries
2024-07-15 12:48:59 <KipIngram   > darkling: I think the floating point equivalent will probably be system-specific.
2024-07-15 12:50:21 <GeDaMo      > There's an FDEPTH in the standard
2024-07-15 13:04:42 <KipIngram   > Fair enough, and that's hte name I would have chosen too.  I still doubt it's as "universal" as DEPTH.  My guess would be that almost all systems including the ones that don't profess to be standard would have DEPTH - it's got "history" behind it.
2024-07-15 13:57:58 <veltas      > KipIngram: It's not universal because the standard doesn't specify whether it's the same stack as the parameter stack, or a separate stack
2024-07-15 13:58:08 <veltas      > Although every implementation I know of has a separate stack
2024-07-15 13:58:43 <veltas      > darkling: So unfortunately there's this inherent non-portability of the floating point stack
2024-07-15 14:41:23 <KipIngram   > Yeah, I've debated with myself about that same stack / separate stack question.
2024-07-15 14:41:56 <KipIngram   > We've talked a little about the vector floating point instructions - I figure the best way to use those resources would be to keep the data in place.
2024-07-15 14:42:34 <veltas      > Yeah I don't think you can do vector stuff on a stack effectively, agreed
2024-07-15 14:42:45 <veltas      > Unless you want a bit vector :P
2024-07-15 20:45:21 <darkling    > If I want to convert a number from the stack into a text string, I thought I could use <# #S #> to give me ( addr n ) on the stack, where addr is a pointer to n chars containing the converted string.
2024-07-15 20:46:02 <darkling    > That's my reading of the standard, at least. However, when I try it, I'm getting a single number on the stack, which appears to be the length of the string plus 19.
2024-07-15 20:46:11 <darkling    > What am I doing wrong here?
2024-07-15 20:47:07 <darkling    > https://dpaste.com/HW8Y7CJJZ
2024-07-15 20:48:47 <GeDaMo      > The number on the stack should be a double cell value
2024-07-15 20:49:38 <darkling    > That doesn't seem to be the case here.
2024-07-15 20:49:46 <darkling    > I'm using pforth
2024-07-15 20:50:55 <GeDaMo      > https://ideone.com/kNFRwX
2024-07-15 20:51:01 <GeDaMo      > That's gforth
2024-07-15 20:51:24 <darkling    > Oh, sorry, I see -- the *input* should be a double cell.
2024-07-15 20:52:09 <GeDaMo      > Yeah
2024-07-15 20:52:26 <darkling    > Yes, that's much happier.
2024-07-15 20:52:28 <darkling    > Thanks.
2024-07-15 20:52:32 <GeDaMo      > :)
2024-07-15 21:02:41 <lf94        > My poland dude found the website
2024-07-15 21:02:51 <lf94        > https://forthsalon.appspot.com/
2024-07-15 21:03:05 <lf94        > I definitely think we could make a better version of this
2024-07-15 21:03:22 <lf94        > crc -^
2024-07-15 21:18:03 <tbsp        > Ohhh, that's neat
2024-07-15 21:25:22 <lf94        > For real these are great for the My4th system
2024-07-15 21:25:27 <lf94        > Very fun stuff
2024-07-15 22:19:28 <darkling    > I realise that this is probably about as portable as a neutronium suitcase, even if it exists, but is there anything commonly used for concurrent programming? (Specifically, I want to run code in parallel on more than one core).
2024-07-15 22:31:00 <lf94        > I think people just run forth on each core lol.
2024-07-15 22:33:59 <darkling    > Fair. :)
2024-07-15 22:36:22 <lf94        > I don't really know what multi-core IPC looks like
2024-07-15 22:36:34 <lf94        > I imagine it's just...talking over memory, or even better, caches
2024-07-15 22:37:39 <darkling    > Plus concurrency control on the memory (mutexes, semaphores).
2024-07-15 22:39:44 <darkling    > Caches are worse, because if you have a separate cache for each core, you have to deal with cache invalidation on writes, and ensure that that's consistent with locking.
2024-07-15 22:41:24 <lf94        > True I was thinking like shared cache higher up
2024-07-15 22:41:31 <lf94        > Since machines have so many level of caches today
2024-07-15 23:08:34 <KipIngram   > I thought the processor hardware handled cache line invalidation.
2024-07-15 23:10:34 <darkling    > Mmm. Yes. Different value of "you", I guess. :)