<tpbsd>
tabemann, how do you use your assert word ?
<tabemann>
<expression> assert <exception>
<tabemann>
if <expression> is zero, then <exception> is raised
<rdrop-exit>
hi tp and tabemann
<tabemann>
hey guys
<tpbsd>
I've read the source but cant find what a valid exception name is
<tabemann>
that's because you need to read the kernel source
<tpbsd>
hey rdrop-exit! Zen Guru of Forth
<tabemann>
but don't worry, you can make up your own exceptions
<rdrop-exit>
hi Forth Master Technician (tm)
<rdrop-exit>
tp is an exception ;-)
<tabemann>
like : my-exception space ." this is my exception" ;
<tpbsd>
yeah and it's syntax is 'pita'
<tpbsd>
tabemann, that looks like a ordinary definition ?
<tabemann>
it is
<tabemann>
exceptions are ordinary words in zeptoforth
<tabemann>
all they do is print a useful message to the user
<tpbsd>
i find that confusing, when is a string a exception ?
<rdrop-exit>
tp, it's a fallback exception handler
<tabemann>
yes
<tpbsd>
expecially when a hardware exception makes very terminal things happen
<tabemann>
it's called if the exception is never caught
<rdrop-exit>
you can intercept the exception in your code and do what you think is appropriate
<tabemann>
yes
<tpbsd>
ok, Ive just learned a new thing :)
<rdrop-exit>
if you don't the exception eventually percolates up to the outer interpreter
<tabemann>
like you can do things like : catch-my-exception try dup ['] my-exception = if drop ." caught my exception" 0 then ?raise ;
<tabemann>
this catches my-exception and prints a useful message, otherwise it passes the exception into the next exception handler
<tabemann>
*onto
<tpbsd>
0 1 = assert my-exception this is my exception ok
<tpbsd>
ok, got it
<tabemann>
there's something funny about that - it shouldn't be printing "ok"
<tpbsd>
thats at the terminal
<rdrop-exit>
Not all Forths have an "ok" prompt
<tabemann>
oh you entered <enter> after the message appeared
<tpbsd>
rdrop-exit's doesnt because it isnt 'ok'
<tpbsd>
tabemann no
<rdrop-exit>
My Forths aren't line-oriented
<tabemann>
okay, I just checked
<tpbsd>
tabemann I entered this "0 1 = assert my-exception"
<tabemann>
in my exception handlers I normally put a CRLF at the end of the exception string
<tpbsd>
i would too usually
<rdrop-exit>
I prefer "averts" and "triggers"
<tpbsd>
but the ok wouls still be there just below the message
<rdrop-exit>
<things are ok> averts problem-exception
<tabemann>
what's triggers for?
<rdrop-exit>
<things are not ok> triggers problem-exception
<rdrop-exit>
different conditional
<tabemann>
assert is kinda confusing in a way, so I'll adopt that scheme
<tabemann>
assert normally in most languages raises a special assertion exception
<tpbsd>
I have a 'assert' but it's a technicians assert not a programmers one
<tpbsd>
as a tech Im concerned with making sure that registers are doing what I tell them to do, and thats where I use my assert
<rdrop-exit>
AVERTS raises on 0
<rdrop-exit>
TRIGGERS raises on non-zero
<rdrop-exit>
I use whichever goes most naturally with the logic
<rdrop-exit>
that comes before it
<rdrop-exit>
I use AVERTS more often than TRIGGERS overall
<rdrop-exit>
but sometimes TRIGGERS is more natural
<rdrop-exit>
<everything under control> averts <disaster>
<rdrop-exit>
;-)
<rdrop-exit>
<I'm lost> triggers <panic>
<rdrop-exit>
:-))
<rdrop-exit>
I also have SUPPRESS for suppressing an exception
<rdrop-exit>
try something SUPPRESS panic
<rdrop-exit>
TRY <something> SUPPRESS panic
<rdrop-exit>
here's an example, when your interpreting from the keyboard rather then loading from a block or file, you might want to just beep when the user makes a typo instead of printing an error message
<rdrop-exit>
the above example suppress the undefined word exception and the not-a-number exception and beeps instead, other exceptiions proceed as normal
<tabemann>
back
<rdrop-exit>
* suppresses the ...
<tabemann>
ddd
<tabemann>
whoops
<rdrop-exit>
ddd? triggers whoops
<rdrop-exit>
the "?dup 0;" is not neccessary, it's an optimization
<tabemann>
right now the kind of optimizations I'm aiming for are memory ones, not processor time ones
<tabemann>
specifically with regard to compiled code
WickedShell has quit [Remote host closed the connection]
<rdrop-exit>
the most effective way to minimize target footprint is to use a tethered Forth
WickedShell has joined #forth
<rdrop-exit>
nothing goes on the target that isn't needed on the target for the target application
* tabemann
likes to be able to just connect to the board with an MCU and make it do stuff
<tabemann>
*connect to the board with a terminal
<rdrop-exit>
if you use a JTAG tether you can make your board do stuff right away, no need to install anything on the board
<rdrop-exit>
and you don't need a terminal on your PC, just use your PC forth
* tpbsd
hopes tabemann will make a tethered cortex-m Forth
<tabemann>
rdrop-exit, tethered only removes the overhead of the kernel
<tabemann>
my real problem isn't the kernel's size but rather the size of the code generated from forth
<rdrop-exit>
no, all headers and the outer interpreter can be on the PC
<tabemann>
this is not an issue that'd go away with going tethered
<tabemann>
my problem is that the compiled forth code is far more voluminous than the assembled kernel code - even though the assembled kernel code is also full of headers, because it's meant to be callable from forth
<rdrop-exit>
you don't need headers on the target if your using a PC Forth instead of a terminal program to talk to the target
<rdrop-exit>
* you're using
<tabemann>
as I said, the headers aren't why the code's taking up so much space
<tabemann>
because the kernel also contains headers, yet is far more feature-dense than the compiled code
<tabemann>
anyways, I need to get to bed
<tabemann>
bbl
<rdrop-exit>
it's not just headers, it's everything related to the outer-interpreter and compiler
<rdrop-exit>
goodnight tabemann
<tabemann>
when I say kernel, all of those things are part of it, because they need to be in the kernel can compile anything to begin with
<tabemann>
*so it can
<rdrop-exit>
you compile from your PC, just replace your PC terminal program with a Forth
<tabemann>
anyways, bedtime for real now
<rdrop-exit>
stay healthy
<rdrop-exit>
no terminal required, no gnu target tool chain required, just your PC Forth
<tpbsd>
rdrop-exit, as a user of both on-board and tethered forth, I'm with you on the advantages of a tether
<tpbsd>
the tethered Forth I have can produce a 100 byte bootable binary blinky, thats so small Gcc would probably not compete
<rdrop-exit>
what I find strange is that commercial Forths have been tether oriented for 30+ years, but open source Forths are very rarely tethered
<rdrop-exit>
actually more like 35+ years
<tpbsd>
I dont know why that is, but I have observed that there are hardly any OSS cortex-m forths
<tpbsd>
Mecrisp-Stellaris is the best by far and the *only* current and maintained OSS cortex-m Forth out there
dys has quit [Ping timeout: 264 seconds]
<tpbsd>
tabemann's is coming along nicely, his progress would give SARS-CoV-19 a run for it's monery!
<tpbsd>
but it's far from finished
<rdrop-exit>
I suspect ARM is a pita target
<tpbsd>
perhaps, plus most Forth writers are programmers and have no hardware experience. cortex-m doc is *massive* it scares many away
<rdrop-exit>
Even x86 is massive nowadays
<tpbsd>
it scares most hobbyists away, thats why old obsolete 8 bit chips like Atmel MEGA328 are still so popular
<tpbsd>
the only stable, non crashing x86 Forth I have any confidence in is Retro
<tpbsd>
or Mecrisp-Stellaris under QEMU
<tpbsd>
Ive tried almost every Forth out there and many are unfinished, slow, crashy junk
<tpbsd>
and a lot are so old now, they cont compile on a modern system
<tpbsd>
cont = wont
<rdrop-exit>
It's easier to make one's own than to rely on a hobbiest's experimental Forth
<tpbsd>
maybe for you
<tpbsd>
but I'm slowly coming to that same belief
<rdrop-exit>
that's only because you started Forth very late
<tpbsd>
yeah, I was 60 at the time
<rdrop-exit>
exactly
<tpbsd>
but Ive been designing and deploying micros since 1974 along with machine code, assembly lang etc
<rdrop-exit>
if you had started early, you would have a Forth that evolved with you over decades
<tpbsd>
but Im still not a programmmer, Im a tech
<tpbsd>
ahh thats a good point
<tpbsd>
ok you win!
<rdrop-exit>
how many people can say they know every aspect of their development environment intimately and it's perfectly adapted to their needs
<rdrop-exit>
that's the payoff
<rdrop-exit>
and they can change anything they want
<tpbsd>
I'm 100% with you there
<tpbsd>
Ive been satisfied that I can build my own dev system and make small changes to my tethered and on board forths so far
<rdrop-exit>
A new Forther could start with an simple minimal Forth like eForth, and if they cycle between using and adapting it over years, they'll end up with a Forth uniquely suited to their needs
<rdrop-exit>
the more they use it, the better it becomes
<rdrop-exit>
the problem is most new Forthers bite off more then they can chew and try to make the ultimate Forth right off the bat when they barely understand what they're doing
<tpbsd>
I've noticed that
<tpbsd>
if I make a Forth it will be really basic
<tpbsd>
I dont need advanced maths or graphics
<tpbsd>
I just twiddle bits in registers
<rdrop-exit>
the best way to build a sophisticated system is to evolve it from a small system that works
<rdrop-exit>
"evolve" being the key word
<tpbsd>
that makes perfect sense
<tpbsd>
darn it, I'm actually interested now
<rdrop-exit>
I forget who said that, I'm paraphrasing
<rdrop-exit>
Making a Forth is a fascinating learning experience
<tpbsd>
to a programmer!
<tpbsd>
it would probably be a frustrating experience for me
<tpbsd>
Im a hardware guy
<rdrop-exit>
to anyone who likes to have a deep understanding of their tools
<tpbsd>
well I do, but the programmer mindset is different to mine
<tpbsd>
I love the tech manuals that programmers generally hate
<rdrop-exit>
some programmers
<rdrop-exit>
mostly those who see programming as abastraction
<rdrop-exit>
* abstraction
<rdrop-exit>
the typical programmer mindset is not that useful for Forth anyway, I wouldn't worry about it think of your Forth as a device
<proteusguy>
tpbsd, typical programmer mindset doesn't fit forth so well. You just need the mindset of a creator. Someone who deals with the reality of their environment rather than pure abstractions. Hardware guys often take to it easier as rdrop-exit points out.
<proteus-guy>
yeah this channel has some good folk
gravicappa has joined #forth
<tpbsd>
yeah, it's a fantastic channel
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
WickedShell has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
john_cephalopoda has joined #forth
<john_cephalopoda>
Hey
xek__ has joined #forth
`presiden has joined #forth
john_cephalopoda has quit [Remote host closed the connection]
john_cephalopoda has joined #forth
<webchat9>
hey
<`presiden>
...listen
xek__ has quit [Ping timeout: 256 seconds]
<john_cephalopoda>
Hey webchat9
<john_cephalopoda>
Also hi `presiden.
<DKordic>
Greetings everyone.
<DKordic>
When will I be able to IRC from Your Forth john_cephalopoda ?
<`presiden>
greetings
<john_cephalopoda>
DKordic: I don't have my own Forth. I am doing a lot of stuff with crc's RETRO Forth though. And there's an IRC bot for that in the official examples ;)
<DKordic>
OK I am looking for a BareMetal Forth implementation.
<tpbsd>
tabemann, latest commit is drawing full power, is low power disabled ?
WilhelmVonWeiner has joined #forth
<john_cephalopoda>
DKordic: RETRO runs on bare-metal x86.
<john_cephalopoda>
And I wrote an assembler in RETRO, so you can eventually bootstrap RETRO on bare-metal x86.
<tpbsd>
john_cephalopoda, doesn't retro normally run under an OS, I have it running on FreeBSD here ?
<john_cephalopoda>
It does, but it also includes C sources that allow you to run it on x86 natively.