00:00:00 --- log: started forth/20.02.28 00:05:44 --- join: dys joined #forth 00:38:29 tabemann: That's how Z80's PC works as well for relative jumping 00:40:12 The relative offset is referred to as 'e', but the stored value in machine code is e-2 00:40:38 And the range of e is -126 to 129 00:47:32 --- join: rdrop-exit joined #forth 00:51:13 veltas, it seems ARM thumb works differently from what tabemann described 00:54:55 something about the intermixing of 16-bit and 32-bit instructions 00:59:32 Right 00:59:39 I thought thumb was all 16-bit instructions 01:02:34 I have just about zero ARM knowledge 01:07:59 Me too but that is part of my approx. 0 01:12:30 I remember reading in the RISC-V docs that ARM's thumb is a separate ISA, while with RISC-V 16 bits is just an optional extension 01:12:30 hey guys 01:12:45 arm uses 32 bits internally always 01:12:58 hello Forth Master Technician (tm)! 01:13:11 hey rdrop-exit, Zen Forth Guru! 01:13:17 welocme back veltas ! 01:14:02 but thumb goes thru a code converter so that while the user code is thumb, it all winds up as 32 bit arm before executing in the cpu 01:15:20 unlike risc-v you dont get a choice of 32 or 16 bit with cortex-m0 at least 01:15:32 I mean the instruction sizes 01:15:32 So if I understood correctly with ARM you're either in thumb mode or regular mode, while with RISC-V the compressed instructions are just extra instructions added to the base ISA 01:15:53 ARM is like 32-bit PowerPC in that everything is done with 32-bit words, right? 01:15:58 Going to work! 01:16:06 rdrop-exit, with cortex-m0 there is no 'regular' mode, it's thumb or nothing 01:16:23 even tho deep in the guts of the cpu, it's all 32 bit 01:16:35 i think m3 is the same 01:17:44 some chips may be limited to one ISA or the other, but the point I think is that it's not a superset/subset relation 01:18:12 here's a quote from some of the RISC-V lit: 01:18:14 " 01:18:15 RV32I instructions are indistinguishable in RV32IC. Thumb-2 is actually a separate ISA with 16-bit instructions plus most but not all of ARMv7. For example, Compare and Branch on Zero is in Thumb-2 but not ARMv7, and vice versa for Reverse Subtract with Carry." 01:18:35 Cortex-M use the 32/16 bit Thumb2 instruction set, except the M0/M0+ which use almost pure Thumb1 16 bit instructions with just a few system management 32 bit instructions. Choose Thumb2 or ARMv7-M for both. They don’t support original ARM instructions at all. 01:19:50 the point I think is that there is no superset/subset relation between non-thumb and thumb ISAs 01:19:53 i think risc-v probably has a lot of modern advantages but it's still new 01:20:02 rdrop-exit, agreed 01:21:06 for instance Mecrisp-Stellaris on STM32F103 (cortex-m3) is faster than mecrisp-quintus on the gd32VF103 risc-v 01:21:47 yes, RV is definitely still wet behind the ears 01:22:23 my GCD benchmark is the same for cortex-m3 at 75 mhz and risc-v at 104 MHz 01:22:29 which surprised me 01:23:21 by the same token, at 75 Mhz, cortex-m3 is 3.5x faster than cortex-m0 at the same speed with the same benchmark 01:23:49 I'm not one for benchmarks anyway as I have all the speed ill ever need with a m0 at 8Mhz 01:23:59 I would assume your ARM optimizer is more mature than your RV one 01:24:17 or is this a pure assembly benchmark? 01:24:21 thats what Im assuming also 01:24:29 no, theyre all Forth benchmarks 01:24:57 mecrisp-quintus is fairly new compared to the arm versions 01:25:10 makes sense 01:25:11 the arm versions are years old in fact 01:25:41 the dodgy risc-v doc isnt helping either 01:26:30 in comparison the STM/ARM documentation is a masterpiece of comprehensive and easy to read tech info 01:27:03 If you want to get a feel of the earlier ARM and Thumb, check this precious little doc from 1996 01:27:04 http://www.home.marutan.net/arcemdocs/ARM-ARM-RevB.pdf 01:27:15 I've only read the standards for RV, not the docs of a particular implementation. 01:27:39 I found the standards to be fairly legible as far as such things go. 01:27:53 I'm now forming the opinion that the Chinese Gigadevice company who make the GD32VD103 have copied a lot of the ARM doc 01:28:10 and they have been quite slack about it 01:28:36 For peripherals that's not surprising 01:29:26 for instance the GD32VF103 (risc-v) doc just copies stuff from the GD32F103 (cortex-m3) doc verbatim in some cases, yet they are utterly different ISA 01:29:42 thats what I assumed at first also 01:29:59 I mean the GD32F103 is STM32F103 'compatible' 01:30:14 both are M3 cores 01:30:29 the GD32VF103 is a risc-v core 01:30:41 they even have the same pinouts 01:31:17 thanks X-Scale ! 01:31:44 I think all this copying will set GD back years because of all the confusion 01:32:09 customers will just tire of all the wrong info and wasted time 01:32:36 It may be RV core, I imagine they're trying to ease adoption for current ARM users by making the rest as close to what you'd expect with existing ARM based products 01:32:57 i dont think thats the reason 01:32:57 (by they, I mean Gigadevices) 01:33:31 cheaper for them too, if they make them as close as they can 01:33:35 I think GD 'cloned' the STM32F103 peripherals so they could make immediate profits 01:34:08 i mean if you clone a chip, mark it as the chip that you cloned, you can sell it immediately into espablished markets 01:34:40 if you make your own version with your own part numbering the profits will take years longer to be realised 01:34:59 as the market adopts it or not etc 01:35:55 sadly I think GD had no Zen masters on the board because they didnt seem to realise that everything has two sides 01:36:24 sure, that's the case with their ARM clone, but the RV is a different CPU 01:36:24 quick profits have resulted in a market that has little trust of GD 01:36:40 thats right ... except .... 01:36:50 drum roll 01:37:17 again to realise quick profits, GD used the same 'compatible' peripherals they used in their STM32F103 fakes 01:38:07 I agree the GD32VF103 is a huge improvement, a chance for GD to go 'legit' 01:39:36 my new stm32f103 diagnostics binary found a GD32F103 in a Chinese 'blue pill' board recently 01:39:56 neat 01:40:01 the chip has poor quality markings but they are of a STM32F103 01:40:08 so a blantant fake 01:41:20 someone is relabelling GD32F103's in China as STM32F103's 01:42:01 and putting them in 'blue pill' boards, but the Western buyers are now wise to this stuff 01:42:05 hopefully the RV market will mature, so that we see more than just clones of ARM-based products with the CPU switched out 01:42:45 yeah, it's time for Chinese boards with their own Chinese MCUs, no fakes 01:43:07 their prices are good, the chips seem fine 01:43:19 the doc sucks, but that can improve 01:45:00 --- join: xek__ joined #forth 01:45:08 I also found out that Russian interests have licensed some ARM cores 01:45:30 theyre making low volume variants legally, mainly rad hardened versions! 01:45:41 so silicon on saphire I guess 01:46:33 --- quit: gravicappa (Ping timeout: 265 seconds) 01:46:47 gotta walk the dogs, catch you later :) 01:46:58 --- quit: rdrop-exit (Quit: Lost terminal) 01:47:16 cya, thanks for the chat 01:47:35 --- join: gravicappa joined #forth 02:56:56 --- join: iyzsong joined #forth 05:11:44 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 05:26:18 --- join: dddddd joined #forth 05:43:37 --- quit: Kumool (Ping timeout: 240 seconds) 06:08:52 --- join: Kumool joined #forth 07:06:14 tp: I got inlining working 07:15:27 --- quit: jsoft (Ping timeout: 258 seconds) 07:33:08 --- quit: tabemann (Ping timeout: 240 seconds) 07:47:45 --- join: tpbsd joined #forth 07:47:45 --- quit: tpbsd (Changing host) 07:47:45 --- join: tpbsd joined #forth 07:47:45 --- quit: tp (Read error: Connection reset by peer) 08:02:48 --- join: tp___ joined #forth 08:02:48 --- quit: tp___ (Changing host) 08:02:48 --- join: tp___ joined #forth 08:02:48 --- quit: tpbsd (Read error: Connection reset by peer) 08:06:42 --- quit: tp___ (Read error: Connection reset by peer) 08:06:42 --- join: tpbsd joined #forth 08:34:38 --- join: tp___ joined #forth 08:34:38 --- quit: tp___ (Changing host) 08:34:38 --- join: tp___ joined #forth 08:34:49 --- quit: tpbsd (Remote host closed the connection) 08:39:29 --- quit: tp___ (Ping timeout: 240 seconds) 08:39:31 --- join: tp joined #forth 08:39:32 --- quit: tp (Changing host) 08:39:32 --- join: tp joined #forth 08:41:59 --- quit: jpsamaroo (Ping timeout: 260 seconds) 08:42:00 --- quit: tp (Read error: Connection reset by peer) 08:42:08 --- join: tp joined #forth 08:42:09 --- quit: tp (Changing host) 08:42:09 --- join: tp joined #forth 08:45:48 --- join: tpbsd joined #forth 08:45:48 --- quit: tpbsd (Changing host) 08:45:48 --- join: tpbsd joined #forth 08:45:48 --- quit: tp (Read error: Connection reset by peer) 09:00:20 --- quit: tpbsd (Remote host closed the connection) 09:00:40 --- join: tpbsd joined #forth 09:00:40 --- quit: tpbsd (Changing host) 09:00:40 --- join: tpbsd joined #forth 10:03:42 --- quit: dave0 (Quit: dave's not here) 10:26:35 --- quit: dys (Ping timeout: 248 seconds) 11:39:41 --- join: WickedShell joined #forth 11:44:56 --- quit: gravicappa (Ping timeout: 258 seconds) 12:32:47 --- join: nmz joined #forth 12:33:11 --- join: [2]MrMobius joined #forth 12:34:00 --- quit: MrMobius (Ping timeout: 258 seconds) 12:50:14 --- join: jpsamaroo joined #forth 12:57:06 --- join: MrMobius joined #forth 12:59:06 --- join: [1]MrMobius joined #forth 12:59:18 --- quit: [2]MrMobius (Ping timeout: 258 seconds) 13:02:08 --- quit: MrMobius (Ping timeout: 255 seconds) 13:02:09 --- nick: [1]MrMobius -> MrMobius 13:25:04 --- join: [1]MrMobius joined #forth 13:27:20 --- quit: MrMobius (Ping timeout: 255 seconds) 13:27:21 --- nick: [1]MrMobius -> MrMobius 13:47:48 --- join: [1]MrMobius joined #forth 13:48:48 --- quit: MrMobius (Ping timeout: 240 seconds) 13:48:48 --- nick: [1]MrMobius -> MrMobius 14:00:25 --- quit: _whitelogger (Remote host closed the connection) 14:03:29 --- join: _whitelogger joined #forth 14:03:41 --- join: xek_ joined #forth 14:05:48 --- quit: xek__ (Ping timeout: 240 seconds) 14:47:13 --- join: xek__ joined #forth 14:49:42 --- quit: xek_ (Ping timeout: 258 seconds) 15:11:30 SRC DST LD or DST SRC LD ? 15:11:41 Replace 'LD' with 'MOV' if you want 15:42:41 --- join: rdrop-exit joined #forth 15:46:45 veltas, parameter order is the same whether prefix or postfix is used 15:48:29 Thanks 15:49:38 np 15:50:34 Writing Z80 assembly words at the moment 15:50:39 as an exercise 15:50:49 cool 15:58:11 it's not uncommon for Forth assemblers use a comma at the end of an opcode's name, e.g. 15:58:43 bx cx mov, 16:02:01 the implication being that the word commas (lays down) code into the dictionary 16:04:42 but it's not a universal practice 16:55:54 Also supposedly increases readability for multiple instructions on one line 16:57:52 I don't have too strong an opinion on this, will add commas if I feel like it at some point 17:15:26 --- join: tabemann joined #forth 17:18:22 --- join: dave0 joined #forth 17:40:25 and I got multiline entry working! 17:40:54 (it should have worked from the beginning, but there was a bug that was corrupting the stack between lines entered) 17:40:58 nice 17:41:22 * tabemann should fix string literals 17:42:10 cool 17:44:07 rdrop-exit! g'day! 17:44:43 --- join: iyzsong joined #forth 17:45:12 hello Forth Master Technician (tm)! 17:45:57 some days I feel like a junior technician, but not today ;-) 17:46:33 what'd'ya do? 17:46:48 today I think I will get the stm32 'touch sensing' working 17:47:28 it's ready to go, the config is done, I just need to enable the interrupt 17:48:01 excellent 17:48:29 I've revamped my cortex-m interrupt' page at last: https://mecrisp-stellaris-folkdoc.sourceforge.io/interrupts.html#interrupts 17:48:39 hopefully it's a bit more sensible now 17:49:21 Ive added tips I found critical in the page 18:03:04 kudos 18:03:53 the cortex-m interrupts are a bit more complex than my old 8 bitters :) 18:06:06 --- join: X-Scale` joined #forth 18:08:31 --- join: gravicappa joined #forth 18:08:35 --- quit: X-Scale (Ping timeout: 255 seconds) 18:08:36 --- nick: X-Scale` -> X-Scale 18:10:44 okay, gonna head home - bbl 18:11:37 ciao tabemann 18:15:20 --- quit: tabemann (Ping timeout: 255 seconds) 18:23:32 --- join: boru` joined #forth 18:23:35 --- quit: boru (Disconnected by services) 18:23:37 --- nick: boru` -> boru 18:34:35 --- join: jsoft joined #forth 19:04:50 --- quit: gravicappa (Ping timeout: 255 seconds) 19:58:45 --- join: tabemann joined #forth 20:17:14 --- quit: dddddd (Ping timeout: 260 seconds) 20:30:15 --- join: X-Scale` joined #forth 20:31:13 --- quit: X-Scale (Ping timeout: 240 seconds) 20:31:14 --- nick: X-Scale` -> X-Scale 21:20:34 hey guys 21:20:53 hey tabemann 21:21:01 does anyone know how to get gdb to disassemble when the PC is in no known function? 21:23:06 not me 21:31:17 okay, figured it out 21:42:24 --- quit: _whitelogger (Remote host closed the connection) 21:43:32 I've implemented rdrop-exit's suggestion re a single bit CMSIS-SVD template 21:43:41 \ GPIOF_MODER (read-write) 21:43:42 : GPIOF_MODER_MODER15 ( %XX -- ) 30 lshift GPIOF_MODER ; 21:43:54 thats for bits > 1 21:44:14 15 bit GPIOF_OTYPER \ GPIOF_OTYPER_OT15 21:44:23 abd thats for bit = 1 21:44:49 where 'bit' = : bit ( u -- u ) 1 swap lshift 1-foldable ; \ turn a bit position into a binary number. 21:45:28 --- join: _whitelogger joined #forth 21:46:05 the generated code is the same size, I think the "bit" makes it less wordy, more readable 22:47:32 --- quit: _whitelogger (Remote host closed the connection) 22:50:35 --- join: _whitelogger joined #forth 23:59:59 --- log: ended forth/20.02.28