<MrMobius>
veltas, interesting that you said 3.5mhz z80 is like 2mhz 6592. Ive only ever heard 3-4x difference
<tabemann>
hey guys
<tp>
hey tabemann how goes Zeptoforth ?
dave0 has joined #forth
<tabemann>
busy working on my emit capture code
<tp>
"emit capture code" sound interesting
<tabemann>
what it does is allow the user to specify output data to compare against, with it signaling a failure if it does not match properly
<tabemann>
and it, well, has some bugs itself that I need to fix
<tp>
tabemann, aha part of your unit test stuff ?
<tabemann>
yes
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
iyzsong has joined #forth
<crc>
tabemann: capturing output for automated testing sounds useful; I'll borrow the idea for my testing system
rdrop-exit has joined #forth
<MrMobius>
i bought a copy of Test Driven Development in Embedded C
<MrMobius>
hopefully the concepts apply to other languages
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
<rdrop-exit>
good morning Forthwrights c[]
<cmtptr>
goodnight!
<rdrop-exit>
sleep tight
<cmtptr>
i will sleep as tight or as loose as i want thanks
<rdrop-exit>
:))
kori has quit [Read error: Connection reset by peer]
<tabemann>
back
rdrop-exit has quit [Ping timeout: 265 seconds]
rdrop-exit has joined #forth
_whitelogger has joined #forth
_whitelogger has joined #forth
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
jedb has quit [Remote host closed the connection]
jedb has joined #forth
tabemann_ has joined #forth
tabemann has quit [Ping timeout: 260 seconds]
<Zarutian_HTC|>
rdrop-exit: reminds me. Was FCode of Open Firmware a splendid idea?
<rdrop-exit>
Seemed great to me, but anything Forthy is a hard sell to the general computing world no matter how good
dddddd has quit [Ping timeout: 272 seconds]
tabemann_ is now known as travisb
travisb is now known as tabemann
<tabemann>
for some reason people cannot wrap their brains around something being both A) low level and B) dynamic, interactive, and reflective at the same time
<rdrop-exit>
they're too used to relying on libraries for any heavy lifting
_whitelogger has joined #forth
andrei-n has joined #forth
<rdrop-exit>
most programmers today have too much to unlearn to get anything out of Forth, they're too busy trying to contort Forth to conform to they're biases thereby killing the goose without ever grokking its true nature
<rdrop-exit>
* their biases
<andrei-n>
What would you recommend if someone wants to learn Forth?
<tp>
write lots of Forth ?
<andrei-n>
rdrop-exit says that it's not enough...
<rdrop-exit>
ignore the standard, focus on semantics not syntax
<andrei-n>
What does it mean? Can you give an example?
<rdrop-exit>
When trying to understand a word, focus on understanding the code that gets layed down when it is compiled
<rdrop-exit>
Forth has no syntax to speak of
<rdrop-exit>
This is why syntactical specifications of Forth seem convoluted
<rdrop-exit>
Start with an understanding of the various threading models
<rdrop-exit>
Pick a Forth, understand which threading model you're dealing with
<rdrop-exit>
For any word that confuses you, look at its source, then look at its object code (or intermedate code)
<rdrop-exit>
* intermediate
<andrei-n>
Sounds complicated...
<rdrop-exit>
Understand the subtleties of the different "times", interpret time, compile time, execution time
<rdrop-exit>
It really isn't complicated, although it may seem so at first
<rdrop-exit>
The threading model has a major impact, it "colors" the entire Forth
<rdrop-exit>
There's a good article from Brad Rodriguez (IIRC) that explains the different threading models
<rdrop-exit>
The book Interpretation and Instruction Patch Coprocessing covers all the threading models (even including LISP's) in the first couple chapters
<rdrop-exit>
Forth is easiest to understand from the bottom up
<rdrop-exit>
There are really only two advanced topics in Forth, metacompilation and cross-compilation.
<rdrop-exit>
The book I mentioned earlier is Interpretation and Instruction *Path* Coprocessing
<rdrop-exit>
bbl
rdrop-exit has quit [Ping timeout: 256 seconds]
<veltas>
MrMobius: I don't know why people think this, I think it's because the C64 etc had better video modes so you got much faster graphics, even though the CPU was slower. But the CPU is definitely slower, in all profiling I've done where I've just implemented the 'same' stuff on each.
<veltas>
C64 had 1MHz 6502 if I remember rightly
<veltas>
I'm unsure because I was comparing with the Oric Atmos at the time, which does have a 1MHz 6502
<veltas>
BBC Micro had 2MHz 6502 which is more comparable, it's faster at some things and slower at others
<veltas>
So for raw CPU performance the 6502 acts a bit closer to 2* as fast for the same clock speed
xyh has joined #forth
xyh has quit [Remote host closed the connection]
<veltas>
And don't get me started on the machine code's verbosity, a 64K 6502 machine is a bit like having a 32K Z80 machine, if you write it all in machine code.
rdrop-exit has joined #forth
gravicappa has joined #forth
<veltas>
rdrop-exit: Do you consider abstract computer science data structures to be a non-forth bias?
iyzsong has quit [Ping timeout: 260 seconds]
reepca has quit [Remote host closed the connection]
reepca has joined #forth
iyzsong has joined #forth
reepca has quit [Remote host closed the connection]
reepca has joined #forth
<rdrop-exit>
I don't understand the question, algorithms and data structures in and of themselves aren't biases, they're mathematical+engineering tools. I guess one may have biases that affect which one is selected or how it is implemented.
reepca has quit [Ping timeout: 246 seconds]
<tp>
rdrop-exit, I took your advice a little while ago "rdrop-exit> For any word that confuses you, look at its source, then look at its object code (or intermedate code)" and immediately understood what the words were supposed to do :)
<rdrop-exit>
Cool tp! :)
<tp>
after disassembling the words ( bit@ cbit@ and hbit@ ) I realised their differences
<tp>
Id been trying all kinds of tests and was very confused
<tp>
of course after looking at the assembley code it's all too obvious
<rdrop-exit>
Forth is very concrete :)
<tp>
I had never used cbit@ or hbit@ before, as bit@ was all I needed to test a bit
<tp>
I'm writing a doc page on them, so had to find out what they actually are supposed to do
<tp>
basically they all test a single bit, but they either fetch a cell, halfword or byte to do it
<rdrop-exit>
I figured as much
<tp>
oddly Ive never looked at the assembly before in cases like this
<tp>
id just try a number of tests or email the author
<rdrop-exit>
I normally would just use 8@ 16@ 32@ or @ and then isolate the bit(s) I need, although if your CPU has some amount of bit addressable memory it makes sense to combine the fetch and isolation in single primitive
<rdrop-exit>
I remember reading somewhere that ARM's had "bit banding" which amounts to the same thing
<tp>
the cortex-m0 which I use doesnt have bit banding
<rdrop-exit>
(sorry I meant b@ not 8@)
<tp>
LDR, LDRB and LDRH instructions load the register specified by Rt with either a word, byte
<tp>
or halfword data value from memory. Sizes less than word are zero extended to 32-bits
<tp>
before being written to the register specified by Rt.
<tp>
so thats the difference with those thre bit test words
<rdrop-exit>
masked memory write primitives are more common than masked memory read primitives
<tp>
perhaps not in my embedded work
<rdrop-exit>
e.g. I have %16! ( x mask a -- ) which would end up being a RMW on most CPUs
<tp>
because the MCU has special registers that set or clear bits without requiring a mask
<tp>
the register has no read ability
<rdrop-exit>
also %b! %32! %!
<tp>
time has moved on since you last programmed eniac
<rdrop-exit>
right, in such cases you can use the regular store primitives, no need to pull out the masked ones
<tp>
;-)
<tp>
exactly
crest has quit [Ping timeout: 265 seconds]
<tp>
here is a masked write using the "bis!" Word
<tp>
: GPIOB_BSRR_BS0-bis! 0 bit GPIOB_BSRR bis! ; ok.
<tp>
see GPIOB_BSRR_BS0-bis!
<tp>
200003A6: F640 movw r0 #0C00
<tp>
200003AA: F2C4 movt r0 #4001
<tp>
200003A8: 4000
<tp>
200003AC: 0001
<tp>
200003AE: 6903 ldr r3 [ r0 #10 ]
<tp>
200003B0: F053 orrs r3 r3 #1
<tp>
200003B2: 0301
<tp>
200003B4: 6103 str r3 [ r0 #10 ]
<tp>
200003B6: 4770 bx lr
<tp>
Bytes: 18 ok.
<tp>
ironically I used this for ages to write to the "BSRR" register not realising it needs no mask
<tp>
when I did wake up and use a write, I saved 4 bytes
<tp>
: GPIOB_BSRR_BS0! 0 bit GPIOB_BSRR ! ; ok.
<tp>
see GPIOB_BSRR_BS0!
<tp>
200003E4: 4000
<tp>
200003E6: F2C4 movt r0 #4001
<tp>
200003E2: F640 movw r0 #0C00
<tp>
200003E8: 0001
<tp>
200003EA: 2301 movs r3 #1
<tp>
200003EC: 6103 str r3 [ r0 #10 ]
<tp>
200003EE: 4770 bx lr
<tp>
Bytes: 14 ok.
<rdrop-exit>
yes, if the CPU has special RMW capabilities, one should take advantage of them when applicable
<tp>
yeah, even if one just uses the mask word without thinking
<tp>
<doh>
<rdrop-exit>
Forth is all about "thoughtful" programming ;)
<tp>
I dont believe the MCU reads and masks in the case of the BSRR register, it just ignores all zeroes written to the register perhaps ?
<tp>
the only registers with this facility control the GPIO port bits
<rdrop-exit>
I assume so, it basically gives you a way to avoid RMW in your code in certain specific circumstances
<tp>
for any other register one has to mask first, even if Mecrisp-Stellaris does that with the "bis!" or "bic!" Words
<tp>
yeah, and it makes good sense
<rdrop-exit>
which is always a good thing, and should be leveraged when and where available
<tp>
Im not sure why we have bit@ cbit@ and hbit@, perhaps a byte read is faster than a halfword or cell ?
<tp>
i wonder if alingment has anything to do with it ?
<tp>
Address alignment
<tp>
multiple word access, or where a halfword-aligned address is used for a halfword access.
<tp>
There is no support for unaligned accesses on the Cortex-M0 processor. Any attempt to
<tp>
An aligned access is an operation where a word-aligned address is used for a word, or
<tp>
Byte accesses are always aligned.
<tp>
perform an unaligned memory access operation results in a HardFault exception.
<rdrop-exit>
I guess, although since those operators deal only with a single bit, the single-byte version would seem sufficient for all needs.
<tp>
not if the bit in question is say bit 32 and well outside the range of a byte ?
<tp>
the byte only deals with bits 1 -8
<rdrop-exit>
sure but then you fetch the byte that has the bit in question
<tp>
hmm, I dont know how to do that with cortex-m0
<tp>
I know how to save 4 bytes into a cell using a offset
<tp>
I guess the reverse applie
<tp>
s
<rdrop-exit>
unless you're determining which byte at runtime, the single byte one would seem sufficient, but on some architectures it would be slower
<rdrop-exit>
I'm sure he has a perfectly valid reason for having the different variations, I'm just not familiar with ARM
<tp>
I'm guessing one may read an array of bytes and then test the bit in a byte, but the bit@ requires as parameters, a bit position and an address
<tp>
Im sure the author does, hopefullI may discern the reason within a decade after he designs it ;-)
<rdrop-exit>
probably has to do with alignment making the other versions faster when applicable like you said
<tp>
I have read that alignment operations can be very expensive on cpus that offer it
<tp>
which the cortex-m0 does not (auto alignment)
<rdrop-exit>
These might also be words he's used to having in his Forths regardless of CPU
<tp>
only the more complex mcus have it such as the cortex-m4 etc
<tp>
another good theory!
<tp>
he loves the MSP430 by Ti and wrote that first. ARM was a later 'port'
<rdrop-exit>
This is why my VARIABLE takes a size/alignment parameter in my Forths
<rdrop-exit>
byte variable thingy
<tp>
and then you add whatever mcu black magic is needed later ?
<rdrop-exit>
32-bit variable doodad
<tp>
depending on whats being used ?
<rdrop-exit>
cell variable a-nice-cell
<tp>
well I have a better idea of why the extra bit@ words may exist now
<rdrop-exit>
my variable pads the start address so that the variable ends up size aligned on a natural power-of-2 boundary
<tp>
rdrop-exit, are you aware that the RISC-V mcus have a inbuilt cycle counter ?
<rdrop-exit>
yes
<tp>
rdrop-exit, yes, thats required with cortex-mo unless one likes 'hard faults'
<tp>
some people recently used that cycle timer to try and determine the start up of the MSU
<rdrop-exit>
the RISC-V Debug Module spec has a veritable smorgasbord of capabilities (if the particular implementation implements all the options)
<tp>
the longan-nano board uses the GD32VF103 mcu, and like most Chinese chips is short on specifics
<tp>
one of those specifics is the fact that the chip has 128KB flash chip glued on the die of the MCU
<tp>
and that the flash chip downloads it's data into 128KB of RAM on the chip at power up
<tp>
this makes the chip faster than a alternate using flash at bootup, but also makes it slower to boot as it downloads the dat from flash into r`am
<tp>
so some people used the RISC-V timer to try and find out whats happening
<rdrop-exit>
the RISC-V specs leave so much up to the implementation, complete documentation from the vendor is critical to figure out which options are actually implemented
<tp>
true
<rdrop-exit>
In some cases I think the spec leaves too much up to the discretion of the chip vendor
<tp>
perhaps Chinese users get the full doc in Mandarin ?
<rdrop-exit>
Kinda like the ANS Forth spec
<tp>
but the english doc is woeful
<rdrop-exit>
could be
<rdrop-exit>
I like things to be pinned down more
<tp>
it looks like the doc for their STM32F103 clone was used as a template and they havent rewritten important parts yet
<tp>
perhaps it will evenyually
<rdrop-exit>
bah humbug
<tp>
no ?
<rdrop-exit>
I'm sure you're right, I'm just expressing my disgust
<tp>
currently the doc claims the same peripheral reset method as the STM32VF103, except it's not as shown by GD's own demo software
<tp>
I have been spoilt by the STMicro doc that eveyone hated until they started trying to read the Chinese doc
<tp>
the STMicro doc is a work of high class literature in comparison
<rdrop-exit>
:)
dddddd has joined #forth
jedb has quit [Remote host closed the connection]
jedb has joined #forth
proteus-guy has joined #forth
jedb has quit [Ping timeout: 256 seconds]
jedb has joined #forth
dave0 has quit [Quit: dave's not here]
jsoft has quit [Ping timeout: 264 seconds]
rdrop-exit has quit [Quit: Lost terminal]
rann has quit [Ping timeout: 272 seconds]
ovf has quit [Ping timeout: 240 seconds]
dys has joined #forth
ovf has joined #forth
ovf has quit [Max SendQ exceeded]
rann has joined #forth
ovf has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
gravicappa has quit [Ping timeout: 272 seconds]
gravicappa has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 240 seconds]
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 264 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
xek has joined #forth
xek has quit [Quit: Leaving]
antaoiseach has joined #forth
xek has joined #forth
antaoiseach has left #forth [#forth]
gravicappa has quit [Ping timeout: 260 seconds]
lonjil has quit [Quit: Quit.]
dddddd has joined #forth
lonjil has joined #forth
lonjil has quit [Client Quit]
lonjil has joined #forth
lonjil has quit [Client Quit]
lonjil has joined #forth
lonjil has quit [Quit: Quit.]
lonjil has joined #forth
dys has quit [Ping timeout: 272 seconds]
TCZ has joined #forth
reepca has joined #forth
C-Keen has quit [Quit: WeeChat 2.6]
xek has quit [Ping timeout: 264 seconds]
Zarutian_HTC| has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
andrei-n has quit [Quit: Leaving]
C-Keen has joined #forth
Zarutian_HTC has quit [Ping timeout: 260 seconds]
TCZ has quit [Quit: Leaving]
Zarutian_HTC has joined #forth
reepca has quit [Read error: Connection reset by peer]