2022-07-01 06:34:30 <crc         > lisbeths: I've never explored reversible computing so couldn't say
2022-07-01 09:03:18 <KipIngram   > I think it's possible to implement any boolean circuit in a reversible fashion if you want to.  The gates that would otherwise result in information loss accumulate "junk."  You can implement a quantum computing circuit that is fully equivalent to any "classical logic" network, and those produce such junk - a standard part of many quantum algorithms is "junk reversal."
2022-07-01 09:04:36 <KipIngram   > Usually what you want in a quantum computer is for the output to be a superposition of many inputs, and input cases that have different junk output won't super-pose with one another properly.  So you have to include a section that "reverses out" the junk.  Those bits start out zero - they get junk.  When you reverse the junk out you take them back to zero, and now all of your cases have zero on the extra bits
2022-07-01 09:04:38 <KipIngram   > and will then interfere with one another the way you want.
2022-07-01 09:05:25 <KipIngram   > That junk reversal stuff really felt like a violation of the quantum no cloning theorem to me, but evidently it works, so I'm looking at it the wrong way somehow.
2022-07-01 09:06:11 <KipIngram   > Anyway, all quantum computing operations are inherently reversible - it's not possible to have one that's not.
2022-07-01 09:07:00 <KipIngram   > It's because they're all representable by unitary matrices, and all unitary matrices have an inverse.
2022-07-01 09:08:17 <KipIngram   > The big argument that Stephen Hawking and Leonard Susskind had about black holes had to do with information loss - Hawking contended that Hawking radiation from black holes carried no information; Susskind said that couldn't be because then information would be lost, and quantum theory doesn't allow that.
2022-07-01 09:08:24 <KipIngram   > In the end Hawking conceded the debate.
2022-07-01 09:32:17 <KipIngram   > https://web.cecs.pdx.edu/~mperkows/CLASS_VHDL_99/tran888/lecture003-reversible-logic.pdf
2022-07-01 09:33:05 <KipIngram   > One of the more interesting aspects of all of this is that at the very theoretical level it's actually erasing information that costs energy in computation.  You can reduce the energy required for a reversible computation "without limit" in theory.
2022-07-01 09:33:27 <KipIngram   > Of course we're nowhere near that limit in our computing technology today.
2022-07-01 09:33:56 <KipIngram   > Feynman's Lectures on Computation goes into all this stuff.
2022-07-01 09:34:35 <KipIngram   > I swear, Feynman just had his fingers in pies all over the place.
2022-07-01 09:36:05 <KipIngram   > He was one of the first people to glom onto the idea of quantum computers in the first place - he noticed that the amount of computer time required to model quantum systems rose exponentially with the size of the system - somehow nature was doing something that required a LOT of work to model.  So he speculated that maybe we could turn that around and find a way to take advantage of that complexity, with a
2022-07-01 09:36:07 <KipIngram   > new type of computer.
2022-07-01 09:37:47 <KipIngram   > I remember the day he died - I was in an antenna theory class and the prof walked in and told us.
2022-07-01 09:38:36 <KipIngram   > That was before everyone found out everything in seconds via their phones.
2022-07-01 09:41:52 <KipIngram   > I sometimes think things were better then - the "speed of information" these days leads to people reacting emotionally almost all at once - back then by the time "most people" found things out the first people who found out had had time to settle down.  Overall we reacted more "thoughtfully" to thinks.  These days we have a tendency to go berserk, en masse.
2022-07-01 09:43:29 <KipIngram   > https://www.scribd.com/doc/52657907/Feynman-Lectures-on-Computation
2022-07-01 11:33:05 <MrMobius    > anyone familiar with flashforth? im wondering if i can run it in qemu or similar since i dont have a board to try it on
2022-07-01 11:34:45 <MrMobius    > maybe the microchip ide since that has a simulator
2022-07-01 11:40:09 <lispmacs[work]> MrMobius: Around six months or so ago I spent some time trying to see if I could get FlashForth running in some free software simulator/emulator or other, without success
2022-07-01 11:40:38 <lispmacs[work]> Since I'm a free software advocate, though, I haven't tried any of the Microchip software
2022-07-01 11:41:17 <lispmacs[work]> which is in the end the reason I abandoned Flashforth, since it is now dependent on Microchip's prioprietary compiler to build
2022-07-01 11:41:35 <skvery      > MrMobius  What is your application?  That might influence our recommendation.
2022-07-01 11:42:04 <lispmacs[work]> I spent some time trying to get Flashforth to build with just gcc compiler and linker, but in the end was not able to get a working build
2022-07-01 11:42:34 <skvery      > Why?
2022-07-01 11:44:13 <lispmacs[work]> I had to do some things with the linker script to get the code to be placed at the correct place in memory. I thought I had it figured out, but when I loaded my build on the chip, flashforth wouldn't boot correctly
2022-07-01 11:44:20 <MrMobius    > skvery, im just curious about the assembly output and optimizations so i want to type in some example programs then examine the generated assembly
2022-07-01 11:44:55 <MrMobius    > skvery, so I could use the AVR or pic version assuming the optimizations are mostly the same
2022-07-01 11:46:06 <skvery      > Why not look at Mecrisp or gForth - more modern stuff?
2022-07-01 11:46:57 <MrMobius    > skvery, ive already looked at mecrisp and its optimizations. someone on a podcast was talking about how fast flashforth is and how it can optimize down to a single instruction which doesnt match the optimizations described on the flashforth website so i want to see for myself
2022-07-01 11:49:52 <skvery      > The problem with flashForth as far as I understand is that it uses a cross-compile.  Mecrisp and gForth compiles natively on the chip - pseudo-interpret.
2022-07-01 11:51:11 <MrMobius    > for mecrisp it depends. the one for MSP430 is tethered and optimizes extremely well before transmitting machine code with no core
2022-07-01 11:52:35 <skvery      > MSP430 Mecrisp also uses on-chip compile for bigger chips - only the tiny ones need the tethered version.
2022-07-01 11:56:42 <skvery      > Compiling natively, very close to the hardware is key to get things working bottom-up quickly.  Cross-compilation forth looses that key benefit.  (I find the compile-flash-run cycle wasting a lot of my time.)
2022-07-01 11:57:08 <lispmacs[work]> When I used flashforth on AVR it was compiling on the chip
2022-07-01 11:57:20 <lispmacs[work]> after loading core Forth, of course
2022-07-01 11:57:58 <KipIngram   > In a code threaded system, I'd expect a default behavior of having "very small" primitives just inlined, automatically, instead of called.  And *some* of those (e.g., 1+ and 1-) would just be single instructions.
2022-07-01 12:00:10 <KipIngram   > I guess that qualifies as an optimization, but I hardly think of it as one - just seems like how such a system should work.
2022-07-01 12:00:27 <skvery      > The idea is to profile the program when you need more speed and inline those parts - or assemble them as part of the Mecrisp core (GAS assembler.)
2022-07-01 12:01:38 <MrMobius    > skvery, ya mecrisp is cool because youre cross compiling but you also get the interactivity since the ARM board is simulating the MSP430
2022-07-01 12:03:06 <MrMobius    > skvery, I found the MyFFshell/MyFORTHshell program for windows which seems to be able to cross compile but I can't get it to do anything without a board attached
2022-07-01 12:03:17 <skvery      > Have not used that version.  Have used normal Mecrisp quite a bit on the MSP430 series.
2022-07-01 12:03:21 <MrMobius    > ff-shell.py errored out for me on linux
2022-07-01 12:03:26 <KipIngram   > skvery: Yes, that's my long term plan.  A good profiler and the ability to deploy assembly where I need it.
2022-07-01 12:03:45 <KipIngram   > But I'd still want a code threaded system to do what I said, because it's "too easy not to."
2022-07-01 12:04:53 <KipIngram   > I mean, it's more than "nothing" in terms of complexity, but it really doesn't get much easier than that.
2022-07-01 12:05:31 <KipIngram   > My system's indirect threaded, so inlining isn't available in the same way.
2022-07-01 12:06:57 <skvery      > My latest project is to get Mecrisp going on the microbit V2 and then the BLE interrupts.
2022-07-01 12:08:28 <MrMobius    > actually, i dont think ff-shell or MyFORTHshell does any compiling. hmm, so then flashforth is not cross compiled?
2022-07-01 12:09:56 <skvery      > OK  then the code should be simpler to trace.  Is it C or assembler?  MrMobius
2022-07-01 12:11:37 <MrMobius    > skvery, what do you mean? I just started looking into flashforth today so I dont know much about it yet. there are hex images in the directory to flash to the mcu
2022-07-01 12:18:08 <MrMobius    > although you can build it from the assembly files of course
2022-07-01 12:18:55 <skvery      > seems https://github.com/oh2aun/flashforth/tree/master/pic18/src is the flashforth assembler for PIC18?
2022-07-01 12:26:39 <lispmacs[work]> you can build flashforth with the assembly files but only using the Microchip compiling/linking suite
2022-07-01 12:27:10 <lispmacs[work]> after loading core on the chip, you compile new words on the device itself. at least, that is the way it is with AVR
2022-07-01 12:28:24 <skvery      > In that case mecrisp is more open - uses gas to assemble the core.
2022-07-01 12:28:51 <lispmacs[work]> I was able to build mecrisp without using any proprietary software
2022-07-01 12:29:14 <lispmacs[work]> and use the symbols from that for debugging purposes over SWD
2022-07-01 12:29:17 <skvery      > ^
2022-07-01 12:29:58 <skvery      > ooh have not tried debugging that way...
2022-07-01 12:30:38 <lispmacs[work]> very nice experience, using mecrisp symbols + SWD + gdb
2022-07-01 12:31:28 <lispmacs[work]> though, since mecrisp includes a disassembler (the see word) often you don't need to bother with that
2022-07-01 12:31:51 <lispmacs[work]> https://portal.mozz.us/gemini/gem.librehacker.com/gemlog/tech/20220331-0.gmi?inline=1
2022-07-01 12:32:40 <lispmacs[work]> It can be fun to use SWD + gdb to step through the code though, as described in my post above
2022-07-01 12:33:32 <lispmacs[work]> step through the code, look at registers, etc
2022-07-01 12:33:50 <lispmacs[work]> though for optimization purposes I usually just use the built-in mecrisp disassembler
2022-07-01 12:34:43 <MrMobius    > lispmacs[work], right I know it can be built. the thing im asking is if i can try it out without an AVR board
2022-07-01 12:34:58 <MrMobius    > i might be able to use qemu avr or something
2022-07-01 12:35:31 <lispmacs[work]> MrMobius: I spent a week or two trying to figure out how to get Flashforth to run in Qemu and some other free software simulators but was in the end frustrated
2022-07-01 12:35:59 <skvery      > Mecrisp works without the AVR board - is that the question?
2022-07-01 12:36:22 <lispmacs[work]> Mecrisp is not for AVR, it is for ARM
2022-07-01 12:36:47 <lispmacs[work]> hopefully two threads of thought are not getting mixed up here
2022-07-01 12:37:31 <lispmacs[work]> MrMobius I understood was asking about simulating Flashforth for AVR. I was chatting with skvery about Mecrisp on ARM (Rpi Pico)
2022-07-01 12:37:42 <MrMobius    > skvery, I already clarified that above. im not interested in mecrisp. ive seen how it works and im curious about how flashforth works
2022-07-01 12:38:29 <skvery      > Then I am out of my depth, sz.
2022-07-01 12:39:04 <lispmacs[work]> MrMobius: I think Flashforth still has an IRC channel on freenode, if you still have an account there, and want to check with them
2022-07-01 12:39:14 <lispmacs[work]> also there is their email list
2022-07-01 12:39:43 <MrMobius    > lispmacs[work], how did you install qemu for avr? there is qemu-system-arm, qemu-system-mips, etc but no separate qemu-system-avr to install on ubuntu at least
2022-07-01 12:39:45 <lispmacs[work]> I can only say that I tried to get Flashforth running on free software simulators and didn't find a working solution
2022-07-01 12:42:26 <lispmacs[work]> MrMobius: IIRC, there was no package available on my distro either, so I tried other simulators
2022-07-01 12:43:07 <lispmacs[work]> oh wait, sorry...
2022-07-01 12:43:17 <lispmacs[work]> I use Guix, and it just has one package that covers them all
2022-07-01 12:43:39 <lispmacs[work]> qemu package provides qemu-system-avr
2022-07-01 12:44:27 <KipIngram   > I really should look into making mine run in qemu or something similar.
2022-07-01 12:45:01 <KipIngram   > I want it to eventually be portable across a variety of common platforms - that would really be a good (and low cost) way to pursue that.
2022-07-01 12:45:33 <lispmacs[work]> If I was still interested in Flashforth, I would probably try the Guix qemu-system-avr with the instructions on this page:
2022-07-01 12:45:38 <lispmacs[work]> https://www.qemu.org/docs/master/system/target-avr.html
2022-07-01 12:46:17 <lispmacs[work]> memory is a little fuzzy, but I think I tried this and it didn't work
2022-07-01 12:46:22 <KipIngram   > Well, I'm off until 7/12; maybe I should spend some of that time delving into that.
2022-07-01 12:47:05 <MrMobius    > lispmacs[work], right, that's the link I found for qemu-system-avr. there are no install instructions. installing qemu-system installs 30+ others but not avr
2022-07-01 12:47:06 <lispmacs[work]> something to do with the fact that the only working binary I had was the .hex file provided by flashforth, but qemu wants elf
2022-07-01 12:47:19 <MrMobius    > ah
2022-07-01 12:48:14 <lispmacs[work]> MrMobius: my qemu package on guix does provide a qemu-system-avr, though unfortunately that does not help you
2022-07-01 12:49:14 <MrMobius    > listed here for ubuntu 21 and 22 but not 20 https://pkgs.org/download/qemu-system-avr
2022-07-01 12:49:27 <MrMobius    > linux version fuckery ftw
2022-07-01 12:50:31 <lispmacs[work]> MrMobius: it is actual possible to install Guix on your Ubuntu system and then use it to build Qemu, but not sure if you want to go down that rabbit hole
2022-07-01 12:50:58 <lispmacs[work]> in theory, I could also use Guix to build you a stand-alone Qemu
2022-07-01 12:52:15 <MrMobius    > i dont know anything about guix. im running ubuntu under WSL which is why im on Ubuntu 20 until i get my server back which is ubuntu 22
2022-07-01 12:53:09 <MrMobius    > lispmacs[work], ill try it if you want to give it a try. maybe it will help you out too
2022-07-01 12:53:13 <lispmacs[work]> Debian actually has a guix package available
2022-07-01 12:53:30 <lispmacs[work]> is it available on your Ubuntu version
2022-07-01 12:54:01 <lispmacs[work]> you would just need to install guix, and then "guix install qemu"
2022-07-01 12:55:18 <lispmacs[work]> I think it is only available for ubuntu 22
2022-07-01 12:57:41 <lispmacs[work]> I'm trying out the "guix pack" command to see if I can get you a build of qemu with all dependencies included
2022-07-01 13:03:24 <KipIngram   > On packages of that sort I'm always torn over how to go about it - installing a package from the distro's repos is so easy, but often you wind uup *way* behind the cutting edge.  Building from source is often a crap shoot - sometimes it "just works," but sometimes it can drive you half insane.
2022-07-01 13:04:09 <KipIngram   > I installed ngspice from the repo - I figured that's an old tool and likely wouldn't be missing *too* much from there.
2022-07-01 13:06:34 <lispmacs[work]> KipIngram: let me introduce you to Guix :)
2022-07-01 13:06:58 <lispmacs[work]> rolling release!
2022-07-01 13:07:36 <lispmacs[work]> plus, nifty "time-machine" feature if you want to install from a version of Guix you haven't upgrade to yet!
2022-07-01 13:08:46 <lispmacs[work]> "foreign distro" installs also available if you want to use Guix package but not give up your current distro
2022-07-01 13:10:16 <lispmacs[work]> MrMobius: So, I was able to build a full-contained, relocateable Qemu for you, using "guix pack"
2022-07-01 13:10:36 <lispmacs[work]> unfortunately, however, the tarball comes in at 600 MB, so getting it to you might be a challenge
2022-07-01 13:10:50 <MrMobius    > heh
2022-07-01 13:10:54 <KipIngram   > :-)
2022-07-01 13:11:01 <KipIngram   > I'll definitely look into it.
2022-07-01 13:11:07 <KipIngram   > Sooner or later I really need to.
2022-07-01 13:11:58 <KipIngram   > It may be time - I'm in a "build things" mode right now, but I've shied away from anything involving embedded processors for lack of an "easy vehicle" to use.
2022-07-01 13:12:27 <KipIngram   > But if I had a working build of my Forth for one of the common micros that barrier would just melt away.
2022-07-01 13:12:40 <KipIngram   > And that would open a ton of additional possibilities.
2022-07-01 13:13:33 <KipIngram   > It occurred to me while I was reading the earlier parts of this conversation that I should go through my code and so some re-structuring.
2022-07-01 13:14:09 <KipIngram   > Because scattered about in there I have code that is aimed at setting the host system up the way I want it - like the termios and stuff.
2022-07-01 13:14:44 <KipIngram   > That stuff will need to stay on the host; even if the system itself is on a remote gadget, I'll still likely be *talking to it* from my notebook.
2022-07-01 13:14:51 <KipIngram   > And that's where the screen behavior lives.
2022-07-01 13:15:27 <KipIngram   > So I should go through and segregate all of that sort of thing into a well-defined section.
2022-07-01 13:33:17 <MrMobius    > so i got simavr working and connected to gdb. the first instruction it executes jumps to uninitialized memory
2022-07-01 13:34:23 <lispmacs[work]> MrMobius: what -m device option are you using for simavr?
2022-07-01 13:34:33 <MrMobius    > atmega328
2022-07-01 13:35:52 <lispmacs[work]> I seem to recall running into the same or similar problem with simavr
2022-07-01 13:49:16 <MrMobius    > hmm, so it starts executing at 0x7E00 and the first instruction is to jump to $1AFC. the next instructions look like garbage
2022-07-01 13:49:57 <MrMobius    > the first 8 instructions at address 0 are exactly the same. apparently the reset vector is stored at 0
2022-07-01 13:52:19 <MrMobius    > so if it's an address instead of an instruction, it should jump here which looks like forth code to me: https://dis.yaxpeax.net/avr/F9DD66DD65DD52DD8CDD51D1
2022-07-01 14:05:52 <lispmacs[work]> MrMobius: something I'm wonder about is what bootbit fuse settings are assumed by simavr
2022-07-01 14:05:56 <lispmacs[work]> https://embedds.com/all-you-need-to-know-about-avr-fuses/
2022-07-01 14:06:10 <lispmacs[work]> like BOOTRST, BOOTSZ0, BOOTSZ1
2022-07-01 14:08:29 <MrMobius    > good point. i dont know how those are stored in the hex file
2022-07-01 14:08:36 <lispmacs[work]> they aren't
2022-07-01 14:08:44 <MrMobius    > maybe thats why there are 8k at 0x0 and 350 bytes or so at 0x7E00
2022-07-01 14:08:59 <lispmacs[work]> I believe that that the flashforth tool sets them
2022-07-01 14:09:07 <MrMobius    > ah ok
2022-07-01 14:10:41 <MrMobius    > any clue why the two sets of data in the hex file?
2022-07-01 14:11:20 <lispmacs[work]> i vaguely recall there was some forth system stuff that had to go in a very precise location near the end of flash memory, something to do with the boot process
2022-07-01 14:11:43 <lispmacs[work]> or with flash writing areas, or both
2022-07-01 14:12:19 <MrMobius    > okie dokie. should be able to figure that out
2022-07-01 14:13:23 <lispmacs[work]> https://flashforth.com/atmega.html
2022-07-01 14:13:36 <lispmacs[work]> you see there is a line there showing what fuses have to be set with avrdude parameters
2022-07-01 14:14:19 <lispmacs[work]> not sure how that simavr deals with that
2022-07-01 15:44:12 <MrMobius    > ff appears to run in the microchip IDE but the UART output is blank
2022-07-01 15:44:27 <MrMobius    > in the simulator
2022-07-01 17:42:24 <MrMobius    > I got it to boot and output to the UART in simavr!
2022-07-01 17:42:40 <KipIngram   > Ah, outstanding.
2022-07-01 17:43:36 <MrMobius    > for some reason, simavr thinks the memory at 0x7E00 is a bootloader. if you switch that to be first and the program second, it works and doesnt say anything about trying to load a bootloader
2022-07-01 17:58:36 <lispmacs[work]> MrMobius: How do you switch those?
2022-07-01 18:00:58 <MrMobius    > just copy and paste in the hex file
2022-07-01 19:54:41 <MrMobius    > lispmacs[work], it works on this shareware simulator: https://www.oshonsoft.com/avr.php