01:46:18
##forth
<lisbeths>
crc well this is meant for gnu systems and gnu compliant systems like windows right now. but once I can fully test it then I am going to make a version for microcontrollers. I have to design this so that I can work on systems with kilobytes of ram in the present or terrabytes of ram in the far future
01:46:33
##forth
<lisbeths>
that is unfortunate the last time I asked you about it a few years ago you said you were interested in the idea of a register forth
01:46:55
##forth
<lisbeths>
I have changed my VM significantly. I work on it for a couple weeks at at ime then set it on the shelf for 6 months then work on it again and etcera
01:47:43
##forth
<lisbeths>
how many registers would you recommend I give to the machine?
02:51:07
##forth
<crc>
I think it's a factor of my models being primarily atack machines, and mostly working with Forth. I've explored some use of registers within variations of mg mode!s, but apart from a few cases didn't find them compelling for my particular needs
02:55:25
##forth
<crc>
I've never used more than around 16-20 total in my experiments, though my largest model had far more than that available
02:58:17
##forth
<crc>
Registers might make more sense on a very memory constrained target, especially if you can map them closely to the physical underlying machine
03:06:36
##forth
<crc>
I think your new vm design is interesting enough to be worth taking a deeper examination when I have more free time. (Currently very busy between my dayjob, setting up an array of security cameras for a local church, and getting things finalized for a conference tomorrow/Saturday)
04:11:28
##forth
<KipIngram>
Ugh. It's slightly depressing that a church needs security cameras, isn't it?
04:35:42
##forth
<crc>
yes
04:40:43
##forth
<crc>
We have eight cameras mounted and lines run back to the network cabinet for four of them. Still need to finish the lines for the other four, then I have to setup a computer and finish writing the software for recording & remote access for those who will be helping to watch for potential security concerns
06:55:10
##forth
<lisbeths>
I made these immaculate macro assembler definitions to explain exactly what my most recent VM does but the c macro system is too clunky to run it. but this code I am going to link should improve readability by alot
12:38:19
##forth
<lisbeths>
I just woke up moments ago and I was envisioning the magnetic charges in an SSD, or the voltages in a capacitor. and i was noticing that she signal to these capacities is much more rich and contextual and full of data than a mere digital 1 or 0. I was imagining the level of their charge to be like a stack, and I was wondering if they couldn't be treated as stack data using float-based probabilistic logic systems over logic gates.
16:25:32
##forth
<KipIngram>
lisbeths: This go round I'm writing a Python pre-processor so that I can write my source exactly like I want to instead of being constrained by what my tool can do. The idea is to, as much as possible, wind up with source that can be converted to straight assembly by the Python or can be meta-compiled directly by the finished system later.
16:37:39
##forth
<hello-operator>
lisbeths: They already use multiple voltages levels in the cells used in electronic memory, look up "Multi-level cell"
16:38:39
##forth
<lisbeths>
well I was wondering if you could use them to make a pushdown stack and your words of memory would be probabilities of floats instead of integers
16:38:43
##forth
<KipIngram>
Yeah - QLC flash uses 16.
16:39:14
##forth
<KipIngram>
I just retired from IBM from a group that developed flash-based SSD's, and we were up to QLC-based drives when I left (just a couple of weeks ago).
16:40:09
##forth
<KipIngram>
Other clever things are done with NAND flash - I saw a Veritasium video that talked about them using analog control of the voltage levels to implement matrix multiplication for neural network training.
16:40:28
##forth
<KipIngram>
It's only approximate, since it's analog, but that is very often good enough for that kind of training.
16:40:45
##forth
<KipIngram>
And it's a massively parallel sort of process.
16:41:01
##forth
<KipIngram>
Talk about thinking outside the box.
16:42:55
##forth
<KipIngram>
The energy savings for a given amount of training were stupidly large.
16:45:53
##forth
<hello-operator>
I don't see how? Each cell holds a single value, it is an analogue value and they use every trick in the book to store as much data in a single cell as possible (including lots of error correction), they're using hundreds of electrons to do so. You could make something lossy, but I don't think you would gain much (although KipIngram has highlighted a special case)
16:47:03
##forth
<hello-operator>
You couldn't implement a stack, but you could implement: this cell holds maybe 4 or maybe 5 out of 8 (or however many levels you have)
16:47:53
##forth
<hello-operator>
Not that you would want to use NAND flash for your stack though! (limited R/W cycles, very slow compared to registers / stack close to the CPU)
17:03:07
##forth
<KipIngram>
hello-operator: Each cell is a single voltage, but if you carve that range up into 16 bins then you can store four bits in the cell. That's what's done in QLC flash. SLC = simple digital, two values / on-off, one bit per cell. I think MLC came next and was four ranges per cell, so two bits. Then TLC was eight ranges per cell, three bits, and now we're up to QLC which is 16 ranges or four bits.
17:03:09
##forth
<KipIngram>
And yes - this just makes the precision and effort required to set and read the voltages in those narrower ranges well enough for it to work that much harder.
17:04:19
##forth
<KipIngram>
I wasn't in the development arm of the effort at work - I hired on to the original small company as the software engineering manager, which included the low level firmware that did all that stuff, but when IBM bought the place they imported legacy employees as managers and I went over to performance testing.
17:05:20
##forth
<KipIngram>
But I knew enough about what those guys did to be very impressed with the sophistication of their work - they pulled out every trick in the book to make those things possible. And to get enterprise grade data integrity - NAND flash is really crap stuff and doesn't do a particularly great job remembering things.
17:05:30
##forth
<KipIngram>
I used to joke that those guys made armor out of tissue paper.
17:06:11
##forth
<KipIngram>
And the never ending push for more bits per cell basically just makes it crappier.
17:06:24
##forth
<KipIngram>
So more hoop jumping is required to keep the data integrity up.
17:07:22
##forth
<KipIngram>
One guy there did high-end error detection and correction algorithms in hardware - FPGA logic for things like polynomial field arithmetic and so on.
17:07:53
##forth
<KipIngram>
The code pages were around 8kB, and his stuff could extract the correct data even with over a hundred bit errors in the flash itself.
17:08:46
##forth
<KipIngram>
Those errors accumulate, so there was a background scanner than ran all the time, just reading through the pages at a low rate and monitoring bit error count. When a page got above a certain error threshold it would be re-written clean to a new location and the old page marked for garbage collection.
17:09:28
##forth
<KipIngram>
If you were to turn one of those systems off and walk away for six months, your data would probably be toast when you turned it back on - those maintenance scanners need to be running all the time.
17:27:53
##forth
<hello-operator>
Sorry, I was responding to lisbeths not you KipIngram
17:28:10
##forth
<hello-operator>
my bad
18:13:11
##forth
<NetNoodler>
How does the actions of QUIT differ from ABORT ?
18:38:17
##forth
<vdupras>
ABORT empties PS
18:53:45
##forth
<NetNoodler>
The Return Stack?
18:56:54
##forth
<KipIngram>
QUIT also empties the return stack. It normally does not empty the data stack. ABORT may - I don't know what the standard actually says about that. ABORT often is implemented as ABORT" and can take an error message that gets displayed on the way out.
18:58:02
##forth
<NetNoodler>
So ABORT does a global reset on the engine, while QUIT does not?
19:01:36
##forth
<vdupras>
not necessarily a global reset of the system. For example, all variables stay as they are. Only PS (Parameter Stack), on top of QUIT behavior. Forth implementations may vary
19:04:39
##forth
<KipIngram>
NetNoodler: For instance, the dictionary doesn't get reset. Any disk blocks you've loaded would still be extant.
19:05:17
##forth
<KipIngram>
In older Forths you'd sometimes find COLD, which does do a total system reset - puts you back to the "just started" state.
19:06:19
##forth
<KipIngram>
I normally include COLD in my systems, because usually I copy the code image from where Linux loads it up into a buffer I allocate, and that's where it runs from. So that originally loaded image is still down there unchanged, and can be copied up again if I want to. Makes for an easy COLD.
19:07:41
##forth
<KipIngram>
Linux usually won't let you emit new machine code into the the .data section and make it prot RX; you usually can only do that in buffers you've actually allocated. So I just completely bail on my original .text and .data sections and operate fully out of malloc'd RAM.
19:08:03
##forth
<KipIngram>
Plus that way I can have everything in one contiguous address range.
19:08:49
##forth
<KipIngram>
I've never quite understood why they have that restriction on the .data section, but apparently it makes certain kinds of exploits harder.
20:39:23
##forth
<NetNoodler>
This is on a PDP-8 so memory is whatever I want to do with it
20:45:19
##forth
<NetNoodler>
"One continuous address range" is impossible on a PDP-8 without going to 24-bit addresses everywhere
22:07:25
##forth
<tpnix>
KipIngram, thanks for your expaqnsive description of QLC flash, I found that absolutely fascinating
22:55:45
##forth
<KipIngram>
I was pretty amazed at how much there is to the stuff after I hired onto the little company IBM bought. Definitely a "specialty area."
23:05:56
##forth
<tpnix>
KipIngram, I knew that the desire/need to move beyond binary to ternary etc has been growing for decades, I had no idea that it had progressed so far
23:07:30
##forth
<tpnix>
the rewards are massive as are the problems as you stated, reliability suffers as every additional level results in a worse SNR than binary