00:00:00 --- log: started forth/19.12.14 00:09:13 --- quit: rdrop-exit (Quit: Lost terminal) 00:22:50 --- quit: dddddd (Remote host closed the connection) 00:43:58 --- quit: WickedShell (Remote host closed the connection) 01:52:58 --- quit: ryke (Ping timeout: 268 seconds) 02:14:17 --- join: dys joined #forth 02:15:30 tp: nice 02:16:12 Jookia, new version using the compressed 16bit instructions 02:16:30 oh, how's that? 02:16:39 thumb! 02:16:42 the image is about 19kB vs 27kB 02:16:46 Or finger 02:16:47 Or something 02:17:02 jsoft, lil pinkie 02:17:38 Jookia, matthias rewrote it using the optional compressed instructions 02:17:38 Imagine if they called it big-toe or something random 02:18:00 jsoft, youre a big-toe 02:18:53 No I am a left ear lobe, thank you very much. 02:18:58 sadly the new version uses the latest debian binutils-riscv64-linux-gnu which I dont have 02:19:12 tp: how's your impression of the gd32vf103cb at this point? any good? 02:19:32 I am Jacks unbelieving spleen ... 02:20:04 Jookia I'm still undecided 02:20:19 interesting 02:21:01 Jookia, RISC-V 32 Bit seems pretty impressive I like it, but the old cortex-m3 peripherals suck, especially as Gigadevices has renamed everything 02:21:19 interesting 02:21:37 Jookia, it's a lot of extra work to port my cortex-m3 peripheral stuff 02:22:07 especially considering the peripherals are identical but every register and bitfield has ben renamed 02:22:25 that sounds painful 02:22:58 Jookia, plus mecrisp-quintus for the GD32VF103CB is still experimental and changes are frequent 02:23:00 it is 02:23:52 so in general, right now, I wouldnt use GD32VF103CB in *anything*. By comparison cortex-m0 is cheaper, as fast, as efficient and utterly proven 02:24:58 but ... people will keep comparing the GD32VF103CB to the STM32F103 because it's in the "blue pill" 02:25:40 even tho the STM32F103 is ancient and a PITA compared to cortex-m0 02:29:29 I've decided I'm going to move my Forth from indirect threaded code to a VM 02:30:06 tabemann, hows your Forth going ? 02:31:00 Jookia, I'm not a programmer, I dont really know what a vm is other than typified by qemu etc 02:31:44 tp: Ah, in this case it's going to be a small tiny virtual CPU 02:33:25 A lot of scripting languages for video games use this model, like Lua 02:33:53 why make a virtual cpu, why not use the actual cpu hardware ? 02:34:48 I mean, a cortex-mo usually only has 64kB flash and 8kB ram, thats not a lot 02:35:16 so Im assuming youll need a M4 with 1MB flash and 32kB ram at least ? 02:35:52 No, this is for Linux usage- so resource constraints aren't that big an issue- but security is 02:36:08 So I'm not comfortable allowing the Forth to compile and run its own machine code 02:36:23 ah of course 02:36:33 that makes sense to me 02:36:51 I only use Forth on small embedded myself 02:37:46 Currently indirect threaded code is what I'm using, which I like a lot- 02:37:53 and indeed Forth started on small embedded, mcus like the 6800, 6502 and so on which didnt have a OS back then 02:38:06 But the Linux tooling doesn't have good support for it 02:38:55 Since it's a C world 02:39:00 nowdays Forth seems to have jumped to PC's at least as far as many programmers are concerned 02:39:15 and are written in C 02:39:22 Yeah 02:39:24 yeah, it's definitely a C world 02:39:41 Definately 02:40:02 Im not sure what we are talking bout 02:40:11 good way to lose a embedded programming job ? tell them you use Forth ... 02:40:12 There's two major issues with not using C and instead writing assembly for Linux that I'm hitting 02:40:47 The first being that on Linux/Unix, any kind of portability is done at the libc layer so I'd have to FFI to C 02:40:53 Jookia, you mean using assembly for X86 ? 02:41:06 tp: assembly for ARMv7 (that's what I use as my main machine) 02:41:16 yeah, Linux is all C 02:41:25 RPI ? 02:41:35 Novena board, so it's an i.MX6 02:42:07 The second issue is ELF relocations since everything has to be position-independent-code for 'security' now- so indirect threaded code bloats up the relocation table for every pointer to a place in the binary 02:44:04 why would you want to run Forth on such a machine ? 02:44:19 especially under Linux ? 02:44:53 what does Forth offer you that Linux doesnt ? 02:44:59 on that hardware ? 02:45:28 interactive concatenative programming 02:47:01 I enjoy writing it more than C, Python, Bash, whatever Linux tends to use 02:48:44 The problem is that while the hardware (quad-core cortex a9) is massive overkill for forth, on the desktop it's barely enough 02:50:08 there are languages like factor/nim but they're x86-only (sometimes x86_64-only) 03:07:38 so your Forth runs under the linux OS ? 03:09:09 Jookia, and you use Forth under the Linux os because you prefer Forth to C, Python, Bash, etc, even tho you'll have hardly any libraries or support compared to those languages ? 03:11:44 tp: i'll end up begrudgingly having C interp :( 03:11:45 interop* 03:12:15 as in use C libraries somehow ? 03:13:11 yeah, i'd just compile the interpreter with some words that are written in C 03:14:27 having a virtual CPU would help mitigate issues with that 03:15:32 so your Forth will be interactive in terms of the Linux API but it wont have access to the hardware ? 03:16:07 I suspect youre not after access to the hardware anyway ? 03:20:13 tp: correct, though... linux does provide some hardware access from userspace if you're nice enough 03:20:47 drivers you mean ? 03:21:12 no, you can open /dev/mem if you're root and access bare memory in some cases 03:21:40 I used to use direct access back in 1998 when I wrote a Linux general purpose mcu and flash memory burner in C under the GPL 03:21:43 it's not useful if you want to write things that use interrupts or locks so it's not great 03:21:49 nice 03:22:22 linux's driver API is always in flux so writing easy bindings for it would be too difficult 03:22:35 a proper programmer took it and wrote a driver for the parallel port so it didnt risk clashing with the OS 03:23:39 as the parallel port was what I was directly addressing 03:23:43 yeah that sounds about right, but when it comes to ARM boards with GPIO ports often userspace will just bitbang to the gpios 03:24:16 depends 03:24:56 Mecrisp-Stellaris for Linux has a bunch of APIS for gpios, file i/o etc 03:25:01 even tcpip 03:25:41 it probably runs on your Novena board 03:25:58 yeah likely 03:26:35 i run it here under qemu when I need a Forth and dont have forth hardware connected 03:26:51 interesting 03:28:15 it's really fast on this box 03:28:29 as the terminal uses sockets 03:28:43 rather than a slow 460800 baud serial link 03:44:28 nice 03:48:42 --- quit: iyzsong-x (Ping timeout: 276 seconds) 04:07:46 --- quit: dys (Ping timeout: 265 seconds) 04:57:20 --- quit: smokeink (Quit: Leaving) 06:02:27 just finished my bootable image STM32F103C8T6 "hidden" second 64kB Flash self test word :) 06:03:49 it tests all 'erased' ($FF), then flashes all locations $AA, tests them all, erases them all, flashes $55, tests them all and decides if the Flash has passed 06:07:44 Nerd 06:07:52 :) 06:07:58 Nah good on ya, well done :) 06:08:10 heh, the arduino kids will love it 06:08:45 they have no way to flash a cortex-m from within the chip afaik 06:09:53 this test confirms wether their 64kB flash chip has a 'hidden' second 64kB flash they can use 06:15:03 --- quit: Jookia (Remote host closed the connection) 06:15:03 --- quit: oxford (Read error: Connection reset by peer) 06:16:22 --- join: Jookia joined #forth 06:18:27 --- join: oxford joined #forth 06:31:39 --- quit: jedb__ (Ping timeout: 240 seconds) 06:31:46 --- join: jedb joined #forth 06:33:06 A 'hidden' 64kB ? 06:34:13 --- join: ryke joined #forth 06:39:28 --- join: dddddd joined #forth 06:43:57 --- join: f-a joined #forth 07:31:22 --- quit: dave0 (Quit: dave's not here) 08:29:43 --- quit: f-a (Quit: leaving) 09:27:47 --- quit: tabemann (Remote host closed the connection) 09:27:54 --- join: tabemann joined #forth 09:32:28 --- join: smokeink joined #forth 09:32:59 --- quit: tabemann (Ping timeout: 250 seconds) 10:00:46 --- join: tabemann joined #forth 10:29:37 --- join: f-a joined #forth 11:22:00 --- quit: reepca (Ping timeout: 252 seconds) 11:48:13 --- quit: tp (Remote host closed the connection) 11:48:32 --- join: tp joined #forth 11:48:32 --- quit: tp (Changing host) 11:48:32 --- join: tp joined #forth 11:50:04 --- quit: tabemann (Remote host closed the connection) 11:51:21 --- join: tabemann joined #forth 12:00:27 --- quit: smokeink (Remote host closed the connection) 12:01:19 --- join: smokeink joined #forth 12:17:24 --- quit: f-a (Quit: bbiab) 12:29:23 --- join: X-Scale` joined #forth 12:30:00 --- quit: X-Scale (Ping timeout: 268 seconds) 12:30:25 --- nick: X-Scale` -> X-Scale 12:31:19 --- quit: gravicappa (Ping timeout: 240 seconds) 12:53:11 --- quit: X-Scale (Ping timeout: 250 seconds) 12:55:52 --- join: X-Scale` joined #forth 12:56:35 --- nick: X-Scale` -> X-Scale 14:05:40 --- quit: tabemann (Ping timeout: 245 seconds) 14:43:21 --- quit: ryke (Ping timeout: 265 seconds) 15:15:26 --- join: dave0 joined #forth 15:41:10 Testing Flash at 0x10000 to 0x1FFFF 15:41:10 Erased 15:41:10 Filled with 1010101010101010 15:41:10 Erased 15:41:10 Filled with 0101010101010101 15:41:10 Erased 15:41:14 ~~~~ ALL TESTS PASSED ~~~ 15:41:59 Yay? 15:42:12 definitely :) 15:43:01 this is bootable Forth image that tests the hidden second 64kB flash block in STM32F103C8's 15:43:42 * Robert just dug out some childhood 25AA640 serial EEPROMs, enough for a full 8 blocks of code. Time this FPGA board gets some permanent storage. 15:43:49 STM configure the chip ID as only having 64kB 15:44:14 They secretly add twice as much memory as specified? 15:44:34 What? 15:45:10 yes they do, but it's only because they use the same die in the cheaper 64kB mcu and the more expensive 128kB one 15:45:58 it's the typical marketing thing, make the same product to save costs and enable the extra features in software 15:46:41 this chip is used in a cheap Chinese board known as the 'blue pill' ( and many others) 15:47:29 which are very popylar with Arduino and C users because the board is usually under $2 with xtals, usb socket, headers etc 15:48:21 but it takes a Forth user to actually make a self test program to test the "hidden' 64kB block from within the chip :) 15:54:07 Marketing.. weird stuff. 15:54:23 But I guess good for you. 15:56:02 well good for the millions who have this chip 15:57:07 because the "chip id" says "64kB" only, programmers dont advertise the extra flash and wont program it unless their config is modified 15:57:29 and who can't use a extra 64kB of flash ? 15:58:36 I don't think I ever ran out of program memory on a microcontroller, but then I'm not using them too often. 15:59:42 true enough, but one can use this flash as data storage for a logger etc 16:00:03 well, one can with Forth ;) 16:06:22 tp: how do you know that 64kb isn't part of a bad yield? 16:07:24 Jookia, this was my exact thoughts when I was told about it 16:07:31 hence my test program above 16:07:40 interesting 16:08:05 I'm a tech, failed testing is always my first thoughts 16:08:41 and no one has actually made a self test routine for this 'hidden' second flash block 16:08:54 that I know of 16:09:33 I erase it, then flash all locations with $AA, test all locs for $AA, then erase and do the same for $55 16:09:52 this way every bit is cycled 16:11:35 besides, only hobbyists use these boards, they wont be going into your e-car autonomous driving computer, or Uncle Bobs pacemaker anytime soon 16:12:55 Ive tested one chip about 50 times @ 32,50 C / 90,49 F hasnt failed yet 16:14:52 woo i just exported all my bultin words as headers for my forth 16:20:55 tp: it's still possible that they sell 128kb models as 64kb models if that helps satisfy demand, so it might not help everybody. still, neat hack 16:26:09 --- quit: CORDIC (Remote host closed the connection) 16:39:25 patrickg, yes, another possibility 16:39:48 --- quit: dave0 (Quit: dave's not here) 16:56:01 --- join: tabemann joined #forth 18:27:17 --- join: iyzsong joined #forth 18:43:45 --- quit: jsoft (Ping timeout: 276 seconds) 18:46:21 --- quit: proteus-guy (Ping timeout: 276 seconds) 19:13:44 maybe it's just the same 64K mapped twice. Does the test consider this silly idea? 20:42:37 --- join: gravicappa joined #forth 20:50:19 dddddd, also a good point but the first 64kB Flash block is running the Forth image doing the testing 20:50:55 dddddd, so when I erase the second block, that would erase everything 20:51:57 dddddd, plus, I can view the first and second block, one has data ( the Forth core ) the other has either nothing or my repetitive test data 21:28:35 --- quit: tp (Ping timeout: 245 seconds) 22:01:09 --- join: f-a joined #forth 22:29:05 --- join: dave0 joined #forth 22:36:19 --- join: ryke joined #forth 23:00:25 --- join: jsoft joined #forth 23:16:33 --- quit: dave0 (Quit: dave's not here) 23:18:45 --- join: tp joined #forth 23:59:59 --- log: ended forth/19.12.14