<tabemann>
just the kernel and the basic Forth source code loaded together in flash come out at $B670, including a cornerstone
<tabemann>
well wait there's also a test program in there
<tabemann>
without the test program, but with the cornerstone, it's $B000
Mellowlink has quit [Remote host closed the connection]
Mellowlink has joined #forth
<tp>
hi all!\
<tabemann>
hey tp
<tp>
tabemann, I dl and compiled zeptoforth no problemo
<tabemann>
I'm wondering why zeptoforth compiled code is so non-dense
<tabemann>
cool
<tp>
sadly I have no M4+
<tabemann>
yeah, at the moment it requires an STM32L476 DISO board
<tabemann>
you could always write driver code to make it work on an M3!
<tabemann>
*DISCO
<tp>
I started modifying your console.s then realised that my M4 isnt a + version (L)
<tp>
I have a couple of F407's but the L code is totally different
<tabemann>
the vast majority of the code, as written, should work on any Thumb-2 system
<tp>
I discovered that when I was porting my code to M0+
<tabemann>
the big thing is the driver code
<tabemann>
the code to set the clock, the code to configure the UART and flash, the code to interact with the UART and flash
<tp>
flash will be different
<tp>
clocks are different
<tp>
plus I have too many other projects to finish :)
<tabemann>
but yeah, feel perfectly free to do a pull request and make the necessary changes to port it
<tp>
all I can offer to do is test it if you produce a stm32F4xx version
<tp>
but I dont use the F4 either, Im a cortex-M0 user as you know
<tabemann>
don't expect an M0 version any time soon
<tabemann>
due to the fundamental differences between thumb-1 and thumb-2
<tabemann>
which STM32F4xx version do you recommend?
<tp>
the F4 disco is a good choice, (STM32F407) but it doesnt have a Ethernet port, but has a audio codec. Any F4xxxx is ok, theyre all much the same
<tp>
the only thing that changes between models is the serial port availability and perhaps flash methods
<tp>
I've found that with Mecrisp-Stellaris
<tabemann>
I'll to STM32F407
<tabemann>
*do
<tp>
for instance the erased state of the F0 and F3 are both high, but the f0+ is low iirc
<tp>
at least matthias does all models of STM32xxxx, he flatly refuses to do atmel SAMxxxx because of their flash limitations
<tabemann>
overly large flash write blocks would definitely be aproblem
<tp>
thats the problem
<tp>
he educated me about the complexity of flash, I was blissfully ignorant as the last proms I wrote code to program were eproms and they could be done on a byte by byte basis
<tp>
hmm, as f0 can only be done on a half word basis, does that mean the flash is actually 16 bit bytes ?
<tabemann>
f407 seems to support both halfword and byte flash writes
<tabemann>
whereas stm32l476 seems to support only 16 and maybe 8 byte writes
<tp>
I think the F4 class have a lot of options
<tabemann>
bbl
iyzsong has joined #forth
dave0 has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
* Zarutian_HTC
muses about cpu architectures
<tp>
heyhey Zarutian_HTC
* Zarutian_HTC
is rather insomniac these nights
<Zarutian_HTC>
h'lo tp
<tp>
Zarutian_HTC, but your nights are 24 hours long ?
<Zarutian_HTC>
tp: no, there are actual daylight during the day this time of year
<Zarutian_HTC>
re cpus: a lot of contemporary stuff that is in cpus are due to lack of revaluation of memory design
<tp>
Zarutian_HTC, I'm still amazed that they can make cpus at all. Ive been in this state of amazement since 1974
<tp>
I've heard the process is so complex now that no one person can understand it all
<Zarutian_HTC>
the L caches, branch prediction, out of order exec, pipelining and such all arose from cpus getting faster than the memories they are fetching instructions and data from
<tp>
so Im not surprised that there is lack of revaluation
<tp>
yeah, flash is slow
<Zarutian_HTC>
flash isnt that much slow but having to earase a block makes writing to it slow
<tp>
Ive been working on accurate stack comments lately and had to laugh last night
<tp>
that it does
<MrMobius>
some chips do a cool thing where they fetch a lot of bits in parallel from flash
<Zarutian_HTC>
but I am not talking about the memory cell tech but the arrangement and use of memories
<MrMobius>
so they fill the cache faster than the CPU executes
<tp>
I decided to add the actual stack contents rather than "x" without thinking it thru
<tp>
the first one in a group of 32 bits was file
<tp>
nine
<tp>
oops
<tp>
fine
<Zarutian_HTC>
MrMobious: here is the thing. I have started to look at the L2 cache of an cpu as its actual main memory
<tp>
ill leave you folks to discuss the finer points of cpu design :)
<Zarutian_HTC>
MrMobious: and that got me thinking why the hell is this expensive ContentAddressableMemory being used?
<Zarutian_HTC>
because, the process is being tricked into thinking that it has this vast address space to avail itself of
<Zarutian_HTC>
which has become heavily leaky abstraction as many programming gudies on getting your program to go fast talk about maintaining cache locality
dddddd has quit [Remote host closed the connection]
rdrop-exit has joined #forth
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC| has quit [Client Quit]
gravicappa has joined #forth
<tabemann>
hey guys
<tp>
hey tabemann
<tabemann>
I'm currently working on my f407 port
<tp>
oh cool
<tp>
i can try it out anytime youre reeady
<tabemann>
the main complex point is flash
<tp>
Im using USART2, but there is a possible problem as USART2_RTS is connected to one pin of the audio-codex
<tp>
yeah, I'm not surprised
<tp>
I'll add RTS to it when youre done and probably change the USART number away from 2
<tp>
can you have a configure option to disable your ACK method ?
<tabemann>
back
<tabemann>
tp: not at the moment
<tp>
no problemo
<tabemann>
I made words for sending XON and XOFF
<tabemann>
which can be put in the code instead of ACK and NAK
<tabemann>
the big difference I'm finding with L407 is that with flash I can write individual bytes
<tabemann>
or halfwords
<tabemann>
*F407
<tabemann>
whereas with L476
<tp>
bytes *and* halfwords ?
<tabemann>
I had to have an elaborate system for buffering flash writes
<tabemann>
yes
<tp>
nice
<tabemann>
you can tell it whether you're writing a byte or a halfword
<tabemann>
this will make it much more efficient in space usage
<tabemann>
but in RAM and in Flash
<tp>
the L series may only be a interim type I think as they have replaced the F and L with the G in one variant I have just become aware off
<tp>
with the G having the low power facilities of the L and the speed of the F
<tabemann>
didn't know that
<tp>
i only just found out and it's just my observation
<tp>
i can easily try your XON system
<tabemann>
ugh
<tabemann>
do you know offchance what the erase block size for F407 is?
<tp>
and mine will ignore your ACK
<tp>
no
<tp>
I've never used it with Mecrisp-Stellaris
<tabemann>
because I need to know that before I can adapt the erasure code for Mecrisp-Stellaris to zeptoforth
<tp>
other than to flash it and get a prompt
<tabemann>
and I need to half that working before I can have stuff like cornerstones working
<tp>
of course
<tp>
ill see if I can find out
<tabemann>
okay, I'm commenting out the erasure code for the time being
<tabemann>
I made it so the erasure words exist, but they don't do anything
proteus-guy has quit [Read error: Connection reset by peer]
<tp>
sure
<tp>
thats what I do with my top down designs
proteus-guy has joined #forth
<tabemann>
hey proteus-guy
<tabemann>
tp: what exactly are the ROM and RAM sizes for the F407?
<tp>
looking
<tp>
128 kb ram
<tp>
1024kB flash
<tp>
thats from the Mecrisp-Stellaris mecrisp-stellaris-stm32f407.s
<tabemann>
that's what I thought
<tabemann>
I just pushed the code
<tabemann>
don't expect it to work though
<tp>
easy to test tho
<tabemann>
also, erasing seems to be currently broken in general
<tabemann>
okay, I just pushed new code to remove a reference to the LED driver from the STM32F407 code
<tp>
plus your makefile needs updating with the mcu choice ?
<tabemann>
there's a PLATFORM variable
<tabemann>
and as for the gas parameter, it's just -mcpu=cortex-m4 -mthumb -g which should be the same for both
<tabemann>
compile it with: make PLATFORM=stm32f407
<tp>
ok ta
<tabemann>
any luck?
<tabemann>
oh, and feel free to send me a pull request - I'd be glad to have more people working on this, particularly for getting it to work on other boards and such
<tabemann>
note that I did make some idiosyncretic choices, e.g. b@ b! b, instead of c@ c! c, (because in this day and age one cannot count on a byte being a character, with unicode and whatnot)
<tabemann>
note that I should really get off to bed now
<tp>
sorry busy chatting with daughter`
<tp>
ill leave a outcome message here for you
<tabemann>
oh that's fine
<tabemann>
g'night
<tp>
night-o
<veltas>
Everyone gets to bed as I get on!
<tp>
not me!
<tp>
it's only 1830 hrs here
<MrMobius>
hmm, I wonder if anyone has had this idea before: I write out the stack on every line of code. what if you had a forth that would keep track of that and let you refer to those arguments by name?
<tp>
and 32,00 C :(
<MrMobius>
and it was smart enough not to save copies of anything unless you were gonna access it later
<tp>
MrMobius, I have a 'stack sensitive prompt' that turns red if there is anything on the stack
<veltas>
Nice
<tp>
it's my equivalent of Zaphod Beeblebrox's 'peril sensitive sunglasses' ;-)
<MrMobius>
how does that work?
<veltas>
I would consider allowing a 'PS1' style variable to change prompt to current stack
<tp>
if the stack depth is greater than 0, send out ansi escape sequence for red
<tp>
less than 1, send ansi escape for black
<MrMobius>
what if its exactly in the middle?
<tp>
0.5 ?
<MrMobius>
ya
<tp>
then leave as is ;-)
<veltas>
I have decided to do a tokenised forth because I am interested in allowing as much colon definition complexity as possible with the somewhat limited RAM I have
<MrMobius>
veltas, what system is this?
<veltas>
ZX Spectrum
<MrMobius>
(sorry if I asked before)
<veltas>
It's okay I wouldn't remember either if you did
<MrMobius>
ok good ill probably ask you again then
<tp>
\ designed for a white background with black text, but you can change to suit
<veltas>
I am guessing I am about half done with my forth words and at about 2500 bytes, 256 of which are the token lookup table so that part is not getting bigger
<tp>
nice
<veltas>
I will definitely try and refactor more when I'm done, I want to see how small I can get it
<tp>
anyone who forgets that veltas == Z80 needs some memory pills along with their Quinine
<veltas>
tp: depth 0 > if red then ." ok. " black cr
<veltas>
That is what I'd write to give you an idea of how dedicated I am to saving space
<veltas>
Even though it adds a redundant black
<tp>
veltas, just be direct, my code is crap, it's ok, I'm a technician, I know it's crap
<veltas>
I don't think it's crap
<veltas>
My code is crap I'm a total beginner at Forth
<tp>
i'll never take offence here at being corrected even hopefuly educated
<veltas>
The last few days I've got a significant amount of useful forth words working in colon definitions and have actually been writing Forth and I am getting practice again finally
<MrMobius>
tp, youre not writing for speed anyway so you an relax
<tp>
rdrop-exit spent hours the other day pointing out that my stack comments were crap, afterwards I rewrote all my XML stuff to make them right, and now theyre so much BETTER!
<veltas>
How did they improve?
<tp>
MrMobius, that's true, but as a Forther Im more and more insulted by my own bad and inefficient code
<tp>
veltas, I'm glad you asked :)
<veltas>
My whole approach with Forth is to never write with speed and as soon as it matters I'm breaking out the assembly
<tp>
which sounds perfectly fair
<tp>
I find Mecrisp-Stellaris Forth about 3x slower than machine code created by C
<MrMobius>
meh. unlikely that your inefficiency will ever matter
<veltas>
It will on the Spectrum
<MrMobius>
true
<veltas>
In a game for example
<tp>
and I find mecrisp-across faster and smaller than machine code created by C
<tp>
MrMobius, I agree, in my world a 1MHz Z80 is probably way to fast
<veltas>
MrMobius: But I will not prematurely optimise, don't worry. I wait until it gets in the way then profile
<tp>
but Forth infects all it's practitioners with a love for efficiency imho
<tp>
so Forth can actually beat C for embedded in every area in my experience
<MrMobius>
hmm, what are basing on that its faster?
<MrMobius>
than C
<veltas>
tp: What advice did you get about stack comments?
<tp>
tests on the same simple code
<tp>
veltas, my stack comments were terrible, her is a old example
<veltas>
I wonder how Forth will compete with SDCC for Z80, the output of SDCC is not great (not their fault, Z80 does not lend well to C).
<tp>
my new code now looks for read-only registers and correctly sets the stack comment and provides the only useful action, 'bit@' which tests the single bit
<tp>
it also adds "?" to the Word name
<tp>
bit@ is a test and has only a 1 or 0 output
<tp>
where a register is readonly but multiple bits the resultant Word is
<tp>
: TSC_IOG5CR_CNT? ( %bbbbbbbbbbbbbb -- x ) TSC_IOG5CR @ ; \ TSC_IOG5CR_CNT, Counter value
<tp>
it replaces the bit@ with a '@'
<tp>
there is a lot more but I wont bore anyone
<veltas>
Okay that makes more sense
<tp>
Ill write it up and get comments from rdrop-exit when he is here next\
<veltas>
Not bored just confused lol
<veltas>
Hmm
<tp>
veltas, lol, I cant blame you!
<tp>
I have 17 virtual desktops open and about 6 projects open and keep pasting data from the wrong projects!
<tp>
um, make that 47 virtual desktops
<tp>
so rdrop-exit's efforts getting me to see the error of my ways resulted in BIG improvents for me
<veltas>
nice
<veltas>
I have 3 virtual desktops right now
<veltas>
And like 8 windows
<veltas>
spread between them
<veltas>
Really only one project open
<tp>
i started with one virtual desktop in 1996
<veltas>
Back then we called it a desktop
<tp>
but more were added as the years passed by
<tp>
not on Linux we didnt
<veltas>
KDE?
<tp>
no, Ive never used kde or gnome, Im a speed freak and HATE any delays
<tp>
I alos hate bling
<rdrop-exit>
good afternoon Forthwrights
<tp>
rdrop-exit, the ZEN GURU of Forth!
<rdrop-exit>
hello Forth Master Technician (tm)!
<veltas>
KDE was pretty fast back in 1998, don't know about 1996
<tp>
veltas would have been icewm or something really light
<tp>
veltas I cant remember now
<veltas>
I have never been a big fan of virtual desktops, I only use it in my current window manager because it has no taskbar
<veltas>
Currently using dwm
<veltas>
I like less clutter too, but I apply it to my organisation. Then again, I don't work from home. At work I only usually have about 10 windows and 1 desktop, but I have 2 monitors.
<tp>
veltas, Ive been using icewm as long as I can remember
<tp>
my menu is decades old
<veltas>
I have been using tiling window managers based on dwm for at least a decade, only in the last couple years did I actually switch to dwm itself
<veltas>
I like having a short C program act as my window manager
<veltas>
The question is when are we getting a Forth-based window manager?
<rdrop-exit>
write one
<tp>
rdrop-exit, your efforts educating me about the stack comments have paid huge dividends here!
<rdrop-exit>
cool tp
<tp>
rdrop-exit, there are so many I need to write a article, but for now some can nee seen here, as always your criticism is most welcome
<tp>
i had a hard look at my XSLT code and made some really big changes, tidied it up etc
<veltas>
I have shown some older people at work some improvements to their code and how they work, and some of them have learned from it and some have totally ignored it
<rdrop-exit>
tp, what is the definition of TSC_CR ?
<veltas>
But I have actually been helpful with it, I didn't just go in and tell them all to use a particular paradigm or whatever, or moan about silly little things, and I have learned from them too.
<tp>
here is additional information regarding my nomenclature, this is a C statement for the TSC
<tp>
TSC->IOSCR = TSC_IOSCR_G2_IO4;
<tp>
this is standard C for embedded as used in a STM example circa 2014
<tp>
yes, your system is well thought out as Id expect
<tp>
do you have a example for a GD32VF103 register as yet ?
<tp>
I dont do any JTAG programming so I cant compare to what you have done here
<tp>
for one thing, every peripheral register has a factory 'description' field in CMSIS-SVD, it's what I append to the last comment section of my words
<rdrop-exit>
that's straight out of the RISC-V spec
<tp>
aha
<rdrop-exit>
just a sec, I'll get you the corresponding page
<tp>
how would you use your system to describe the TSC_IOSCR_G2_IO4 bitfield ?
<tp>
rdrop-exit, yep, pretty standard, it's what i'd expect
<rdrop-exit>
as I went through the spec, I just typed in what I needed
<tp>
I understand
<rdrop-exit>
so bacically I define a constant for each register
<rdrop-exit>
and a define a constant for each bitfield
<tp>
of course
<tp>
but that method wouldnt work for me at all
<rdrop-exit>
ok
<tp>
for one, it's not humanly possible to type in all my registers
<tp>
not for any one person
<rdrop-exit>
I only type in what I'm using
<tp>
it must be fully automatic
<tp>
I know
<tp>
Im doing the same, Im only using a STM32F051 ;-)
<tp>
and it has 33 peripherals and 3300 bitfields
<tp>
and it's the smallest of the STM32F mcus
<tp>
some have 20,000 bitfields
<tp>
none of my stuff includes JTAG specs
<tp>
or even SWD specs
<tp>
it's all restricted to peripheral registers
<rdrop-exit>
JTAG isn't relevant to the point
<tp>
well it is because I havent seen a CMSIS-SVD for it
<tp>
otherwise Id have it
<rdrop-exit>
it has nothing to do with JTAG or no JTAG
<tp>
what was the point again ?
<rdrop-exit>
You're focused on generating definitions automatically and for everything which is fine
<tp>
it's not 'fine' it's *essential*
<rdrop-exit>
I type in definitions of registers and bitfields as I need them, while I'm trying to grok them, which is fine too
<tp>
as you may see when you actually have to start using a actual external device
dys has joined #forth
<rdrop-exit>
I will do what I've always done, read the spec of the specific peripheral, encode the registers and bitfields I need, as I'm reading the spec
<rdrop-exit>
then of interactively test my understanding
<rdrop-exit>
the time I spend typing is inconsequential, it's just something I naturally do as I'm reading a spec, any spec
<tp>
sure
<tp>
take ADC0 in a GDVF103 ?
<tp>
thats one of the many peripherals
<tp>
it has
<tp>
21 registers
<tp>
88 bitfields
<rdrop-exit>
not a problem, as I'm reading about those registers and bitfields and trying to grok them, I type
<rdrop-exit>
I do the same thing as I read an ISA, I start coding the assembler for that ISA as I read
<rdrop-exit>
helps me to grok it
<tp>
the term 'not a problem' is very easy to type, actually groking 21 registers and 88 bitfields, then making the ADC work is something else :)
<tp>
and of course, ADC0 requires the cooperation of other peripherals, some much more complex
<rdrop-exit>
exactly, the critical path is not typing in constants, it's groking them
<tp>
no, it's both
<tp>
as a mistake in either is equally fatal to the device working properly
<tp>
trust me, I know this from the paon of a thousand cust
<tp>
and also the pain of a thousand cuts
<tp>
but there is more
<tp>
a mistake in the transcribing and understanding of other peripherals will also stop the ADC0 working
<tp>
and then after 2 years of dilligent fault finding, you discover that the text is wrong, when you look at the CMSIS-SVD
<tp>
do you know how I know the GDVF103 ADC0 contains 21 registers and 88 bitfields ?
<tp>
I didnd count them from the doc
<tp>
Id still be at it if that was the case
<rdrop-exit>
I'm not trying to convince you to do things my way, whatever works for you is fine
<rdrop-exit>
gotta go, wife wants to watch a video, stay healthy
rdrop-exit has quit [Quit: Lost terminal]
<tp>
no problemo thanks for the stack comment criticism, much appreciated
<Bunny351>
bm08:49 ● <veltas> tp: What advice did you get about stack comments?
<Bunny351>
sorry...
<tp>
?
<tp>
Bunny351, mainly that mine were very incomplete and useless :)
<tp>
now less incomplete tho!
<Bunny351>
no, I'm just too stupid to use my irc client correctly... :-)
<tp>
it's not like theyre trivial to use, unlike Forth stack comments ;-)
xek has joined #forth
<Bunny351>
I find it hard to decide whether to use stack comments or not. I hate cluttering up my code but sometimes it really helps in involved code to remind me where I am
<Bunny351>
for colon definitions I always use them, of course.
<tp>
Bunny351, when it comes to embedded I can't see any alternative to tons of comments tho I only stack comments in colon definitions
<tp>
+ use
<tp>
there is this massive divide between programmers of Forth and embedded programmers of Forth in my experience
<tp>
and embedded programming is the closest anyone will ever come to 'write only Forth' imho
<tp>
my theory is that it's impossible to have short, neat, consice Forth code in embedded
<Bunny351>
true. I see a lot of high-level forths with weird ideas but would actually love to see the application of low-level, old-school forth code and thinking in everyday programming on traditional systems.
<tp>
look at the alternative in C ? this looks nice and neat, but without the header file you dont know the details
<tp>
TSC->IOSCR = TSC_IOSCR_G2_IO4;
logand has joined #forth
<Bunny351>
the neatness is superficial and may actually hide information
<tp>
Bunny351, absolutely my opinion also
<tp>
in the above example it does
<tp>
and without the header file which is *never* included with examples, especially in PDF's one has only part of the information
<tp>
here is a article I wrote about the typical C problem I encounter when reviewing C code as adjunct to understanding the configuration of a MCU peripheral: file:///home/tp/projects/programming-languages/forth/mecrisp-stellaris/mecrisp-unofficial-doc/_build/html/touch-sensor.html#stmicro-c-tsc-code-example
<tp>
below it is my working and newly minted stack comment code
<tp>
my "Config Words" are all automatically generated from the CMSIS-SVD file for that MCU
<Bunny351>
indeed. unfortunately documentation nowadays just assumes you use C + an IDE + a bunch of badly documented runtime systems, I guess
<tp>
and a massive number of really ugly header files
<tp>
I often wonder if C programmers ever try and read those header files ?
<Bunny351>
yep. or even autogenerated doxygen-style docs that don't really explain anything
<tp>
in embedded, the contortions the header files go thru is amazing
<tp>
automated doc is really useless in my experience
<tp>
looks pretty, and looks organised but useless
<Bunny351>
but is cheap to produce...
<tp>
and 'better than nothing' I guess
<tp>
it's funny how 'cheap' is used nowadays to justify so may choices
<tp>
for instance the USA put men on the Moon in 1969, but in 2020 Boeing couldn't even put a capsule in the right orbit
<tp>
and their excuse ? 'a clock sync problem'
<Bunny351>
too much complexity and a totally corrupt military industrial complex, but this is probably getting too political... :-)
<tp>
there are some who believe that men could do more in 1969 than now in 2020
<tp>
I agree with you, but the complexity aspect is very relevant to Forth I think
<Bunny351>
todays software is just imploding with complexity and the remedies are only adding more of it
<Bunny351>
partly it's our own fault: we want to many bells and whistles! :-)
<Bunny351>
s/to/too/
<tp>
my own Forth development environment is quite complex now, but it works with a resident embedded Forth the same way they did 40 years ago
<Bunny351>
do you meta-compile?
<tp>
I'm a technician and I use Mecrisp-Stellaris which I didnt (and couldnt) create
<Bunny351>
so it's not bootstrapped using assembly?
<tp>
it's written in thumb1 assembly, so no
<Bunny351>
ah, ok
<tp>
it's assembled by arm-eabi-none
<tp>
I've modified small bits of it, but I build devices with forth, I think of myself as a Forth user
<tp>
I write doc and make my own tooling for Forth, but it's all to enable making things
<tp>
for example a project I've just now finished a new minor version for is a bootable binary to test 'blue-pill' boards from china to see if they contain a 'fake' mcu
<Bunny351>
Huh? what's that?
<tp>
it also tests 'hidden' flash memory in the genuine STM32F103C8 MCU's
<tp>
the 'blue-pill' board is supposed to contain a STM32F103C8 mcu and many dont, they contain cheaper 'clones' or 'fakes' made in China
<Bunny351>
ah, I see.
<tp>
and some of these clones arent 100% compatible with the original, some are in fact better
<tp>
either way, my diagnostic program helps find out what MCU it is
<tp>
it's a Forth system, weighs in under 64kB and does a lot of stuff
<tp>
ID say 99% of the users don't even know (or care) it's a Forth system as it's menu driven
<tp>
as of today sourceforge has counted 194 downloads of it
<tp>
the majority are to the USA and Windows users
dddddd has joined #forth
logand has quit [Ping timeout: 250 seconds]
dave0 has quit [Quit: dave's not here]
xek has quit [Ping timeout: 240 seconds]
iyzsong has quit [Ping timeout: 246 seconds]
Zarutian_HTC has joined #forth
logand has joined #forth
dys has quit [Ping timeout: 256 seconds]
jsoft has quit [Ping timeout: 250 seconds]
Bunny351 has quit [Ping timeout: 240 seconds]
Bunny351 has joined #forth
Zarutian_HTC has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
<tabemann>
hey guys
<Zarutian_HTC>
h'lo
<Zarutian_HTC>
due to discussion elsewhere it occured to me one could set up an recurring timer that when its interrupt fires, just calls PAUSE
<Zarutian_HTC>
or other such task switching word
<remexre>
doesn't that force all your code to be re-entrant, rather than just code that does a cooperative task switch?
<tabemann>
back
<tabemann>
it's essentially just preemptive multitasking, and it forces upon you everything it normally does
<tabemann>
I did just that in hashforth
Mellowlink has quit [Remote host closed the connection]
Mellowlink has joined #forth
<Zarutian_HTC>
remexre: not more than most interrupts do. Critical sections in compareAndStore can momentarily disable interrupts.
<Zarutian_HTC>
this compareAndSwap word is the used for queue or streams between tasks
<remexre>
hm, okay; I'm mainly thinking of the few global structures I have; most of them don't have locks, and instead I rely on "it's unsound to modify this during an interrupt"
<Zarutian_HTC>
that is for inter task communications
xek has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
gravicappa has quit [Ping timeout: 250 seconds]
mtsd has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
xek has quit [Ping timeout: 256 seconds]
mtsd has quit [Ping timeout: 264 seconds]
Zarutian_HTC has joined #forth
mtsd has joined #forth
mtsd has quit [Client Quit]
tabemann has quit [Ping timeout: 260 seconds]
irsol has quit [Remote host closed the connection]