<tabemann>
so you can still enter and compile forth code while it runs
<crab1>
blinky?
<crab1>
also it appears that you are sending your messages doubly
crab1 has quit [Ping timeout: 250 seconds]
<tabemann>
back
<tabemann>
tp:
<tpbsd>
tabemann, congrats on your blinky, another milestone !
<tabemann>
now I'm implementing DO LOOPs, which is a real fucking pain
<tabemann>
there's a reason I rarely use DO LOOPs in my code
<tabemann>
the logic for LOOP and especially for +LOOP is too fucking slow
<tpbsd>
just trying to comprehend how DO LOOPs are done makes my techs brain hurt
<tpbsd>
tabemann, thats a typical programmers atitude tho :)
<tabemann>
on a different Forth of mine I compared BEGIN UNTIL and BEGIN WHILE REPEAT loops with DO LOOP looops
<tabemann>
the first two were so, so much faster when I made them all do the same thing
<tpbsd>
when it comes to Forth in embedded gear a DO LOOP is easy code and TONS too fast for most things
<tabemann>
why?
<tpbsd>
tabemann, I have to use about a million do loops to slow down a MCU running at 48 MHz just to do things in real time
<tabemann>
begin until loops are even faster :D
<tpbsd>
take a 100 millisecond delay, enough time to debounce a switch ?
<tpbsd>
thats probably 100,000 or more do loops at 48 mhz
<tabemann>
I get a slow enough delay with my PAUSE count loops
<tpbsd>
with embedded almost everything a mcu does is way too fast
<tabemann>
where I increment a pause count each time PAUSE is called
<tpbsd>
it's only in the purely software world that a do loop is 'slow'
<tpbsd>
I use do loops all the time in testing, their speed is always irrelevant to me
<tpbsd>
tabemann, it's natural for a Forth programmer to be very interested in the efficiency of his code, it's a itch that grows and grows, even I have it now
<tabemann>
like here, here's my code for compiling a LOOP
<tpbsd>
tabemann, but it also pays to remember that although far, far fewer Forth USERS (like me) exist than Forth programmers, a do loop is a very handy construct to a Forth user in the real world
<tabemann>
\ End a do loop
<tabemann>
: loop ( R: leave current end -- leave current end | )
<tpbsd>
but from my perspective, each instruction is happening at 75 MHz
<tabemann>
but the thing is when you're dealing with a lot of data, all that adds up
<tpbsd>
slow to someone used to a 3GHz Intel, but very fast to someone used to a 1MHz 6800
cartwright has joined #forth
<tpbsd>
except embedded does NOT deal with a lot of data, thats the PC world
<tpbsd>
embedded deals with a lot of I/O thru GPIO ports
<tpbsd>
thats what software only people dont get, and understandably so
<tpbsd>
but NOW I know if I ever have a speed problem with a do loop, that a do until loop is 4.8x faster :)
<tabemann>
BEGIN UNTIL
<tpbsd>
oops
<tpbsd>
tabemann, imagine youre making a washing machine controller in Forth ?
<tabemann>
I've made the mistake of writing BEGIN WHILE UNTIL
<tpbsd>
your confronted with switch debounce, and motor on off control
<tpbsd>
solenoid valves to control water flow
<tpbsd>
I guess you can see how often I use begin until ?
<tpbsd>
but I do use DO LOOP a lot
<tpbsd>
and all those devices are glacially slow compared to even a 1MHZ mcu
<tabemann>
now I have to implement +LOOP
<tabemann>
that one is a fucking pain in the ass
<tpbsd>
thats why I shake my head in wonder when C users on embedded forums rave about a new embedded MCU that can be clocked at 600 MHZ
<tpbsd>
to me 60 MHz is way faster than I'll ever need
<tabemann>
I've almost thought of rewriting hashforth as SRT/NCI because it's too damn slow as being token-threaded
<tpbsd>
in fact when running on a coincell, many MCU's run at 32 KHz !
<tabemann>
too damn slow meaning it does not start instantaneously
<tpbsd>
nothing starts instantaneously
<tabemann>
well the thing is that there's a bunch of raw source code which is loaded into the image
<tabemann>
and at startup time it has to compile it all
<tpbsd>
even a micro takes time to start after the reset button is pressed due to the deliberate RC delay
<tabemann>
and it takes like a noticeable second before it is running
<tpbsd>
I have never measured the delay it takes for a stm32 to start, but it would be in the milliseconds for sure
<tabemann>
zeptoforth seems to boot instantaneously
<tabemann>
but then it does far less on bootup than hashforth
<tpbsd>
well the MCU has a R and a C in it's startup circuit so everything can be syncd
<tabemann>
RC?
<tpbsd>
but PC's and embedded have almost nothing in common in my world
<tpbsd>
a resistor and a capacitor
<tpbsd>
this PC is water cooled, my STM32F103 has no cooling and doesnt even get warm
<tpbsd>
this PC has 32GB dynamic ram, a STM32F103 has 20kB static ram
<tpbsd>
this PC is clocked at 3500 MHz, the STM32F103 at 75 MHz
<tpbsd>
and so on
* tabemann
likes that you can actually reasonably write code to run on bare metal in the MCU world, whereas for PCs there's too much proprietary firmware drivers and shit that make that nearly impossible
<tpbsd>
Ive only written GTK, Perl and SH code for the PC in the last 20 years
<tpbsd>
they were dead easy, but all user stuff
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tpbsd>
but I write code for embedded all the time and can do anything the MCU resources allow, I make my own 'drivers'
<tpbsd>
what programmers call a driver or a library I call 'configuration'
<tabemann>
I'd call that an API
<tabemann>
a "driver" implies a discrete piece of code
<tpbsd>
lol, another programmers term!
<tabemann>
to me at least
<tpbsd>
it's all a bit overlapping I guess
<tpbsd>
well that code is from a discrete piece of code
<tabemann>
like for zeptoforth I have a serial driver - well, two serial drivers - but I find it hard to call them "drivers"
<tpbsd>
it's just there to show readers the important parts
<tpbsd>
exactly, same with mecrisp, the USART code is what I call a configuration
<tabemann>
(the first serial driver is a simpler one to be used before the multitasker is added, and the second includes more advanced buffering support and plays nice with the multitasker)
<tpbsd>
but from a programmers perspective Im sure that there is a 'driver' concept there somewhere
<tabemann>
"driver" implies it is separate from the rest of your OS or your application
<tpbsd>
oh ok
<tabemann>
like at some point it exists as its own shared object or that it is dynamically loadable or like
<tpbsd>
thats well above my pay grade!
<tpbsd>
I'm all solenoid valves and motors
<tpbsd>
soldering and wiring etc
<tabemann>
conversely, I don't understand IO registers and stuff
<tabemann>
like with zeptoforth, everything I've used I've copied from mecrisp-stellaris
<tpbsd>
which are *critical* to embedded, but youre far from alone there
<tabemann>
whereas I'm perfectly comfortable doing things like writing my own multitaskers and like
<tpbsd>
I think the example code people at STM have never seen a MCU myself
<tpbsd>
tabemann, yes, it's easy for a user to see where your expertise lays
<tpbsd>
i see the same things on all the embedded forums, programmers operate in the software world and that forms their world view
<tpbsd>
to a user like me, every peripheral register is like a door into a room containing boxes of different tools, every one is specialised and exciting to learn
<tpbsd>
to me a peripheral register is where the fun parts of a MCU live
<tabemann>
whereas I see it like a space that I get to control completely, all by myself, to essentially create my own OS of sorts for
<tabemann>
whereas on a PC I never get to have complete control, ever
<tpbsd>
theyre like the components of a car, the brake slows the car and stops it, the clutch disables or enables the power from the transmission etc
<tpbsd>
and as one experiments with every car component, I do the same with every mcu peripheral register
<tabemann>
even if there weren't those binary blobs, there's still the fact that there's a hidden secret ARM core buried inside every Intel processor, probably doing the NSA's bidding
<tpbsd>
tabemann, thats true, tho youre at the stage of controlling the MCU ARM registers only
<tpbsd>
tabemann, there is 'hidden' stuff inside all MCU's
<tabemann>
I know that with the DISCOVERY board there's really two MCUs on the board
<tabemann>
one that I control directly, one that I don't that interfaces with the USB and ST-Link and stuff
<tpbsd>
lookat the RPI, it has a hidden controller that sets everything, if you run Linux on a RPI, it sees only what the hidden controller tells it
<tpbsd>
tabemann, yes, on a DISCO board there is the 'programmer' and the 'target' MCU
<tpbsd>
the programmer part can be removed, or better put, I can run a target standalone from the Disco board
<tpbsd>
tabemann, in fact all the stm32's will run standalone with NO external components at all
<tpbsd>
which may seem off to a programmer, but that standalone capability is essential for a microcontroller
<tabemann>
well yes
<tabemann>
when you're actually putting an MCU in a product
<tpbsd>
but lookat all the guff a pentium needs ?
<tabemann>
you don't want to have to rely on a separate MCU just to, say, field upgrade the device
<tpbsd>
theyre just so different
rdrop-exit has joined #forth
<tpbsd>
sure, and you dont need one either
<tabemann>
hey rdrop-exit
<rdrop-exit>
hi tabemann and tp!
<tpbsd>
the DISCO board just has a USB interface for convenience
<tabemann>
well yes
<tpbsd>
hey Zen Forth Guru!
<rdrop-exit>
home quarantine for everybody here
<tabemann>
fun
<tabemann>
I'm surprised they haven't done it here
<tabemann>
I'm seriously going to work tomorrow
<tpbsd>
tabemann, take Microchip MCU's, they all need a separate PICKIT programmer and so on
<tpbsd>
rdrop-exit, wow
<rdrop-exit>
& (loop) converge ; directive
<rdrop-exit>
: loop { a*# # -- }()( r: a lim x -- {a lim x+1}| )
<tpbsd>
rdrop-exit, what does that look like in Forth ? ;-)
<tabemann>
lol
<rdrop-exit>
& is just POSTPONE, I prefer to use a shorter name
<rdrop-exit>
(loop) is the runtime of LOOP
<rdrop-exit>
CONVERGE resolves a series of pending relative forward references
<tpbsd>
thats the awesome thing about Forth to me, theyre all difefrent!
<tpbsd>
rdrop-exit, I had a long chat to my friend in Wuhan about the state of things there
<tpbsd>
he said it's almost over, hes been confined to his apartment for 2 months
<rdrop-exit>
they're talking about 1 month for now here
<tpbsd>
everything is so organised there, food is ordered online and delivered, the govt provides free vegies
<tpbsd>
after hearing from him how organised they are in wuhan I saw Australia's response as 'she will be right mate'
<rdrop-exit>
the population of Metro Manila is 13M
<tpbsd>
I'm sure Wuhan's pop would also be a lot ?
<rdrop-exit>
yes, urban area is 9M
<tpbsd>
the town of Wuhan has been in quarantine for those last 2 months, no one leaves or enters, delivery drivers from outside drop off all the ordered online stuff at a special area outside the town where only specialised people hand it on to specialised people inside the town who deliver it to the appartments
<tpbsd>
and so on
<rdrop-exit>
Same here, Metro Manila is cut off from the rest of the island of Luzon, and Luzon is cut off from the rest of the world
<tpbsd>
he once showed me the Chinese internal shipping system and it makes ours in Auatralia look stoneage
<rdrop-exit>
the last international flights will be leaving in about 48 hours
<rdrop-exit>
it's like a sci-fi movie
<tpbsd>
just be ready for the hordes of flesh eating Coronavirus zombies ?
<rdrop-exit>
he
<tpbsd>
if youre not sure what to do just watch 'zombieland' one and two ;-)
<rdrop-exit>
I'll be ok until I run out of Espresso beans and cigs
<tabemann>
time to quit smoking as long as you have no choice
<tpbsd>
you and 10 million others
<rdrop-exit>
I'm going to walk the dogs on the roof, catch you later
rdrop-exit has quit [Quit: Lost terminal]
<tpbsd>
I wonder which is worse, nicotine withdrawl or the coronavirus ?
<tabemann>
at least you won't die from nicotine withdrawal, even if you may want to
<tpbsd>
tabemann, I only smoked for 3 years, between the age of 30 and 33
<tpbsd>
and even then it was only 3 cigs a day max as more would give me asthma
<tabemann>
good reason to stop
<tpbsd>
but it was damn hard to give it up
<tpbsd>
yeah, I put it down to a temporary insanity
<tpbsd>
id been hunting a lot at night in those days and other hunters smoked and somehow it began
<tpbsd>
which was wierd as my mum was a chain smoker and I grew up hating everything about it
<tpbsd>
she dies of primary lung cancer at 74
<tpbsd>
-s+d
<tpbsd>
even tho she had stopped at age 50
<tpbsd>
but back to forth!
<tpbsd>
I coded right thru the night lastnight, all of a sudden I realised I could see outside because it was light!
<tpbsd>
I had lost all track of time
<tabemann>
what were you working on?
<tpbsd>
a bunch of stuff, mainly updating my STm32F103 project manager to the same level as the STM32F051
<tpbsd>
with the aim of releasing a new STM32F103 diagnostic binary
<tpbsd>
when I went to bed I realised I could just revert everything and keep the STM32F103 projects at the same state because I don't use it in my internal projects
<tpbsd>
and Im not going to either, it's too old, too limited and even tho I have 30 units, I bough them in 2014 before I knew better
<tpbsd>
at least my new library strategy is paying off now
<tabemann>
to me the main question is why not just use whatever balance of A) processing power and B) low power usage fits one's needs
<tabemann>
like with me, I don't need low power, so why not just use something specced out to the max?
<tpbsd>
and thats a common question I have seen for the last 30 years in embedded
<tabemann>
and anyways, the only reason to not use something specced out to the max is if power consumption is a consideration
<tpbsd>
my personal feeling is that embedded development is ALL about the TOOLS, with the MCU choice coming second
<tabemann>
or if there's concerns about issues like binary blobs
<tabemann>
for me at least, I've found gas, gdb, openocd, and st-flash together have been fully sufficient
<tpbsd>
there are other important factors
<tabemann>
I don't even use gdb or openocd anymore now that I can develop primarily in forth
<tabemann>
well yes
<tabemann>
how well the MCU and the board are documented is important
<tabemann>
if there's secret proprietary crap going on is another
<tpbsd>
tabemann, gas, gdb, openocd, and st-flash are recent developments, chronologically speaking
<tpbsd>
tabemann, and the STM tools are fantastic, they do have pretty much everything one needs
<tpbsd>
look at Arduino, they have no GDB, theyre still using print statements to debug
<tabemann>
TBH with Forth I've heavily relied on print debugging - lol
<tpbsd>
lol, so do I, withing Forth programs
<tabemann>
particularly since it is very difficult to debug Forth code with gdb on here, whereas gdb excels with debugging assembly
<tpbsd>
I have a "_P" command that prints the stack with a line number label
<tpbsd>
I use it when the going gets complex
<tabemann>
I added .s but I haven't added line numbers to zeptoforth
<tpbsd>
the line number is automatically inserted so I can correlate the source with the stack prints
<tpbsd>
the line numbers are a VIM thing
<tpbsd>
the command is a VIM command, Forth doesnt know whats going on
<tpbsd>
this is a fine example of what I mean by 'tools'
<tpbsd>
my specialist tools consist of my project manager which only works for STM32 chips
<tpbsd>
if a micro was 100x cheaper and I had no tools, I wouldnt use it
<tpbsd>
look at the Paduk mcus ? theyre available for $0.03 for their OTP version and they have a hardware emulator for each type of Paduk mcu and so on, but I'd never use it because I have my own tool requirements, I wont be forced to use anyones tools
<tpbsd>
especially as everyone elses tools are all about C
<tabemann>
with STM you can work fully in assembly, using very friendly tools, whereas not everything is about that
<tabemann>
e.g. if they require proprietary tooling and shit
<tabemann>
like require you to use their IDE and like
<tpbsd>
exactly, which is what Paduk do
<tpbsd>
and many others
<tabemann>
I'm glad I chose STM for the basis of my MCU Forth
<tpbsd>
my system is so finely tuned to what I want that Arduino programmers and even Forth beginners just stand there looking like zombies when I show them
<tabemann>
aside from the fact that I can't use gdb to debug Forth code, it's been painless
<tpbsd>
it's very hard to beat STM imho
<tabemann>
I imagine how it'd've turned out had I chosen a Microchip product for a Forth
<tabemann>
particularly a PIC chip lol
<tpbsd>
I started with embedded in 1974, so Ive seen and used a lot of different mcu's
<tabemann>
except for PIC32... I've heard that one is sorta better due to really being MIPS
<tpbsd>
well, Flashforth is pretty good and it's been around for at least 7 years for PIC
<tpbsd>
but even flashforth cant run from ram
<tpbsd>
I have 200x PIC's in stock and just never use them. I like PICs, always have and have made decent money with PIC products Ive dsigned and sold in the past
<tabemann>
can it at least flash itself on the fly?
<tpbsd>
sure, it adds words to it's own flash
<tpbsd>
same as Mecrisp-Stellaris
<tabemann>
except, being PIC, it can't run from RAM
<tabemann>
to make a PIC forth which runs from ram you need token or indirect threading
<tpbsd>
flashforth is very polished, but needs the damn java based microchip IDE to compile the flashforth source
<tabemann>
ugh
<tpbsd>
sadly microchip didnt give a damn about non windows for a long time
<tpbsd>
and even now it's a token effort for Linux etc
<tpbsd>
I dont know why Nordstrom doesnt distribute binaries with his flashforth like Mecrisp-Stellaris does
<tabemann>
whereas with STM working on Linux has been without any hitches
<tpbsd>
exactly
<tpbsd>
in 2014 when I 'came back to embedded' after a decade not doing it, I bought several different MCU's to try out
<tpbsd>
only one was dead easy to use with Linux .... STM32
<tpbsd>
all the others were a pain in one way or another
<tpbsd>
I have a box full of MCUs I couldnt use under Linux ranging from Silabs, Atmel, NXP etc
<tpbsd>
Id spend a week on each one and if it was no joy in that time, they went into that box
<tpbsd>
the main problem is that most of them had windows only tools
<tpbsd>
and windows only tools meant they were rejected straight away
<tabemann>
whereas with STM I didn't even need to use their tools - just an OSS ST flasher tool, openocd, and the versions of the GNU tools maintained by ARM
<tpbsd>
exactly, STM worked the first time
<tpbsd>
I think I had to build Openocd, but thats fine
<tpbsd>
then I tried the STM C 'free' environment which wouldnt even work as designed and knew that C wasnt going to work for me
<tpbsd>
I was also looking into Forth at that time and found Mecrisp-Stellaris
<tpbsd>
I started with riscy-pygness on stm32f103 which is why I have those old mcu's
<tpbsd>
and then by sheer good fortune I saw 480x STM32F051 in QFN32 for sale on avenet for $0.56USD each and bought the lot
<tpbsd>
in 3 days I had them on my doorstep from Texas
<tabemann>
back
<tpbsd>
as it turned out I couldn't have chosen a better MCU and package, they do everything I want apart from USB and CAN which I never use anyway
<tabemann>
CAN is basically for cars, from what I know
<tpbsd>
sure, but it's also a very useful noise resistant protocol
<tpbsd>
I know a bit about CAN having used it, but have no plans that require it
<tabemann>
it does have nice things like builtin message prioritization
<tabemann>
and I mean at the hardware level
<tabemann>
not just something of the sort in software
jsoft has joined #forth
<tpbsd>
yeah, it's pretty neat
<tpbsd>
but one also needs the CAN transcievers etc
<tpbsd>
my needs are simpler, machine control
<tpbsd>
one project was a controller for a wheelchair, no CAN or usb needed, the f051 was perfect
<tpbsd>
I can use any kind of input etc, it was a fun project
<tpbsd>
ironically, a delay using BEGIN UNTIL would probably need 4000000 loops to achieve the same time delay that a DO LOOP would need, so offers no real advantage to me for most things
<tpbsd>
the DO LOOP needing 1000000 loops for the same delay
<tabemann>
did you just paste part of the convo from earlier?
<tpbsd>
no
<tpbsd>
i revisited it :)
<tabemann>
oh wait
<tpbsd>
while I was ranting on about CAN, my subconscious was still thinking about DO LOOPs
<tpbsd>
my subconscious is like a Pit Bull dog, it worries every last concept to bits before attacking the next subject
<tabemann>
I'm trying to get my DO LOOP working
<tabemann>
DO LOOP fails at the very end of the looping
<tabemann>
DO +LOOP fails right at the end of the first time around
<tabemann>
okay DO LOOP works now
<tabemann>
?DO LOOP only works partially
<tpbsd>
do you have a MIN as yet ?
<tpbsd>
there was a recent topic on reddit
gravicappa has joined #forth
<tabemann>
now ?DO LOOP and LEAVE work
<tpbsd>
hah
<tpbsd>
in the redit post someone suggested "over - dup 0< and +" as a min solution
<tpbsd>
when I use it with Mecrisp-Stellaris the word is Bytes: 18
<tpbsd>
yet the Mecrisp-Stellaris "MIN" = 10 bytes of assembly
<tpbsd>
so Im guessing that assembly solutions are probably 1.8 times smaller than Forth solutions with cortex-m and clever hand assembly
<tabemann>
okay, I should get to bed
<tabemann>
g'night
dave0 has quit [Quit: dave's not here]
<tpbsd>
cya
cartwright has quit [Remote host closed the connection]
cartwright has joined #forth
dddddd has quit [Ping timeout: 246 seconds]
dave0 has joined #forth
mtsd has joined #forth
dys has joined #forth
reepca has quit [Ping timeout: 240 seconds]
mtsd_ has joined #forth
mtsd has quit [Ping timeout: 256 seconds]
mtsd_ has quit [Client Quit]
xek has joined #forth
WickedShell has quit [Remote host closed the connection]
actuallybatman has quit [Ping timeout: 256 seconds]
crab0 has joined #forth
crab0 has quit [Remote host closed the connection]
crab1 has joined #forth
crab1 has quit [Quit: Ping timeout (120 seconds)]
bluekelp has quit [Ping timeout: 265 seconds]
bluekelp has joined #forth
WickedShell has joined #forth
gravicappa has quit [Ping timeout: 264 seconds]
xek has quit [Ping timeout: 250 seconds]
reepca has joined #forth
CORDIC has joined #forth
DKordic has quit [Read error: Connection reset by peer]
tabemann has quit [Read error: Connection reset by peer]
tabemann_ has joined #forth
absentia has joined #forth
<absentia>
um. Is there a *simple* random number generator that works for gforth? that doesn't require a require random.fs or something? I use to have a 2 liner -- but it now seems completely borked.
absentia has left #forth [#forth]
tpbsd has quit [Remote host closed the connection]
tpbsd has joined #forth
tpbsd has joined #forth
rdrop-exit has joined #forth
<rdrop-exit>
abstentia, xorshift RNGs are simple and fast
tpbsd has quit [Read error: Connection reset by peer]
logand has joined #forth
<logand>
42 >r r> . crashes pforth but prints 42 in gforth. why does it crash in pforth?
<tp___>
pforth can't handle the answer to everything ?
tp___ is now known as tp
<tp>
rdrop-exit, g'day Zen Forth Guru!
<rdrop-exit>
hi tp, Forth Master Tech (tm)!
<tp>
rdrop-exit, no new coronavirus cases in Australia yesterday
<rdrop-exit>
logand, accessing the return stack is usually undefined in interpretation
<rdrop-exit>
excellent tp!
<logand>
tp: haha
<logand>
rdrop-exit: ok, i thought that the other stack was always useable in general
actuallybatman has joined #forth
<tp>
logand, on the embedded cortex-m Forth I use (Mecrisp-Stellaris) >rr> r@ are all handled nicely
<rdrop-exit>
tp, outside of a definition?
<tp>
i never tried that, I doubt it would work tho
<tp>
wrong ... 42 >r r> . 42 ok.
<tp>
I never code outside of definitions except where Im testing hardware in real time at the terminal and I have no need for a pseudo local variable at those times
<logand>
hmm maybe bug in pforth then? or how would one find out if something is only ment to be used inside of a definition? (except crashing)
<logand>
tp: interesting
<rdrop-exit>
normally compile-only words are indicated in the docs
<tp>
if it crashes outside a definition, but not inside, isnt that the answer ?
<rdrop-exit>
some Forths will throw an exception or print an error message
<tp>
crashing indicates undefined or not implemented ?
<logand>
tp: yes it is an answer if i assume it is not a bug
<tp>
*everything* bad throws a exception on cortex-m, there is no escape!
<rdrop-exit>
tp, I didn't mean a processor exception, I'm talking about a Forth exception
<tp>
logand, Im a electronics tech not a programmer, so my Forth usage is that of a user
<tp>
rdrop-exit, I always get confused about the differences there, I'm not sure if Mecrisp-Stellaris even has Forth exceptions
<tp>
rdrop-exit, Forth exceptions are available as add on Words tho
<tp>
perhaps 'forth exceptions' are more of a PC thing than a small embedded thing ?
<logand>
tp: what for devices do you build if i can ask?
<tp>
stm32 always, mainly stm32f051 (cortex-m0)
<logand>
i mean the final product
<tp>
logand, mainly as I have a huge stock of them and they do everything I need, hardware wise
<logand>
ok, but what does it do and what do use it for, the final product?
<tp>
logand, all small custom projects, last one was a wheelchair hand controller to motor drive unit interface
<logand>
i see, cool
<tp>
logand, I'm relatively new to Forth (2014) and learning proceeds glacially
<logand>
glacially because of forth or life? you must be pretty advanced when you use forth for real projects already
<tp>
because of a severe lack of mental horsepower and old age (65)
<logand>
i always wanted to try forth as it seems very interesting but at the same time mentally daunting
<rdrop-exit>
tp, not really, Forth exceptions pretty common since the 90s
<logand>
tp: thanks for the link, i'll have a look
<tp>
rdrop-exit, when Forth became popular on PC's I'll bet
<tp>
logand, I think the old saying 'Forth is easy to learn but difficult to master' has been accurate for me
<rdrop-exit>
I don't think it's related, there have been PC forths since the 70s
<tp>
logand, but for small embedded it has totally changed how I work
<logand>
gforth: 0 0 ! throws invalid memory access, i suppose those are the forth exceptions
<logand>
as it does not crash gforth
<rdrop-exit>
or I should say Microcomputer Forths
<rdrop-exit>
logand, yes
<logand>
tp: changed for the better i suppose:-)
<logand>
rdrop-exit: there were pc's in the 70s already?
<rdrop-exit>
I meant microcomputers
<tp>
rdrop-exit, i always associate the term "PC" with the IBM PC which was released in 1981. Before that they were "6800 development system", "rockwell aim65", "cromenco z80", etc
<tp>
logand, absolutely for the better or I wouldnt be using Forth now