<tp>
thats one advantage of transposing everything to assembly ?
<tabemann>
the weird part is that when I load everything, the problem goes away
<tabemann>
so this might not be related to the changes I made today
<tabemann>
but rather might be an older problem that just happened to surface today because I, for once, didn't load everything
<tp>
true
routeveg has joined #forth
<routeveg>
Hi all
<routeveg>
Im a bit of a newcomer to the specifics of FORTH things, could someone confirm for me, POSTPONE appends the XT associated with the proceeding word, to the currently-compiled definition, right?
<tp>
g'day routeveg
remexre has joined #forth
<routeveg>
(ignoring the immediateness of the word)
<routeveg>
*currently-compiling, I guess I mean.
<routeveg>
Reason I ask is that the docs I'm reading (on the forth website) are a teeny bit unclear on this point, but from what I gather, this is the generally-true statement
<tabemann>
back
<tabemann>
postpone appends the xt associated with the following token to the word being compiled if it is immediate, and appends code to compile the xt associated with the following token to the word being compiled if it is not immediate
<routeveg>
tabemann: Okay, so your last point I am unclear on. There's a word being compiled - if the given token is not immediate, we append code to compile the token, into the currently-being-compiled word
<routeveg>
So the currently-being-compiled word then compiles the token into whatever word is being compiled when that word is being 'run'.
<routeveg>
: my-compile-word postpone token ;
<tabemann>
yes
<routeveg>
oop, *immediate after that . then if I go : my-fn my-compile-word ; , that will put a 'call' to token in my-fn ?
<tabemann>
if you had written : my-compile-word postpone token ; immediate
<routeveg>
Right yeah. cool, okay.
<routeveg>
In that case I wonder why the two functionalities of postpone are in the same function.
<tabemann>
it's because some people to some it's less confusing, even though some people think it's more confusing
<routeveg>
cuz if the following token is immediate, the call to execute the token is compiled into the current definition. Which seems like a pretty different operation to me. I was concerned that I was missing some way in which both of those things are actually the same undernesath
<routeveg>
But I can't see the similarity
<routeveg>
Ah okay; it's validating that some find it more confusing :)
<tabemann>
*some people think it's less confusingg
iyzsong has joined #forth
_whitelogger has joined #forth
<tabemann>
been trying to implement wordlists in zeptoforth
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
<tabemann>
but I keep running into bugs
<crab1>
what are wordlists?
<tabemann>
lists of words - lol
<crab1>
right, but for what purpose, for you to be running into bugs they must not be the same as regular lists
<tabemann>
no, they're not ordinary lists
<tabemann>
they're a way to organize how words are searched for
Zarutian_HTC has quit [Read error: Connection reset by peer]
<crab1>
ah okay
Zarutian_HTC has joined #forth
<crab1>
a data structure to optimize word searching
<tabemann>
it's not really an optimization per se
<tabemann>
it's a way to select which words are searched for
<crab1>
I've gotten a PineBook Pro just this last week, and I want to see if I can turn it into a forth machine
<crab1>
doesn't selecting which words are searched for increase the efficiency of word searching? by reducing the domain of a search
<tabemann>
well, not necessarily, because, e.g., in zeptoforth it has to search through the dictionary for each individual wordlist in the wordlist order
<tabemann>
I had to implement it that way due to limitations imposed by compilation to flash which made it difficult to do it the traditional forthy way
<crab1>
so then it is purely for organization, gotcha
<crab1>
5 processing units sounds like a lot to manage though
<tabemann>
I've been sticking to Cortex-M4 (or, in the case of the Numworks calculator, Cortex-M7) processors
<tabemann>
with my x86-64 laptop serving as a terminal and an editor
<crab1>
4 of them are combined in big.LITTLE architecture though, which seems to be pretty standard
<tabemann>
all those processors seem kind of unwieldy architecture-wise
<crab1>
why so?
<tabemann>
well how asymmetric the processors are
<crab1>
that's the whole point of it though, isn't it
<tabemann>
okay, I'm gonna go to bed because I'm falling asleep right now
<tabemann>
g'night
<crab1>
toodles
_whitelogger has joined #forth
crab1 has quit [Quit: Connection closed]
iyzsong- has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
reepca has quit [Ping timeout: 246 seconds]
va has quit [Read error: Connection reset by peer]
crab1 has joined #forth
jedb has joined #forth
rdrop-exit has joined #forth
jedb has quit [Ping timeout: 246 seconds]
<rdrop-exit>
routeveg, the similarity is in the intent, to postpone the compile-time behavior
<crab1>
Good Morning
<rdrop-exit>
good afternoon
dddddd has quit [Ping timeout: 256 seconds]
<crab1>
how are ya?
<rdrop-exit>
ok, lazy Sunday, just relaxing, alternating between reading and videos
<rdrop-exit>
you?
<crab1>
trying to learn more about my Pinebook to see what I can do with it, and once it's a reasonable time I'll probably go hang out and grill out with some family
<rdrop-exit>
cool
<crab1>
Night shift makes my weekend schedule strange, so I've been up since 20:00 yesterday, it's now 3:37, and I'll probably be up until ~1:00 tomorrow
<crab1>
otherwise I get no human interaction on the weekend
<rdrop-exit>
wow
<crab1>
I'm young and healthy though, I can perform without sleep :)
<crab1>
But I am tiring of my job, I think I may try to get the education required to become an EMT or Paramedic when fall comes
<rdrop-exit>
going without sleep will really screw up your health in the long run
<crab1>
I consider isolation worse though, I basically have to choose between the two
<veltas>
tabemann: "I'm trying to implement the classic Forth vocabulary system, but I'm not sure how I can do it with immutable words"
<veltas>
What do you mean immutable words?
<veltas>
Words that aren't affected by FORGET or something?
gravicappa has quit [Ping timeout: 260 seconds]
karswell_ has quit [Ping timeout: 246 seconds]
Zarutian_HTC has quit [Ping timeout: 258 seconds]
dys has joined #forth
<mark4>
with forget theres usally a word called fence that points to a low waterline maker. only words defined after the word pointed to by fence can be forgotten
<mark4>
the word "empty" forgets every word defined above fernce
mark4 has quit [Remote host closed the connection]
<veltas>
I don't like the definition of COMPARE in standard forth
<veltas>
It's trying too hard to be strcmp
<veltas>
And strcmp() makes perfect sense for null-terminated strings, not for sized memory regions
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
Zarutian_HTC has joined #forth
jedb_ has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
andrei-n has joined #forth
xek_ has joined #forth
gravicappa has quit [Read error: Connection reset by peer]
gravicappa has joined #forth
<tabemann>
veltas
<tabemann>
I mean words written into flash
<tabemann>
anyways, I've decided on doing it a different way
<tabemann>
by tagging each word with a wid
<tabemann>
s/wid/wordlist id
<tabemann>
about standard forth
<tabemann>
I personally don't care about it much; I just implement forth as fits my purposes
TCZ has joined #forth
<crest>
tp: i'm back working on my stlink console
<tabemann>
cool
<crest>
to all those using forth on microcontrollers: what featuress do you want/need from your terminal program?
<crest>
*features
<tabemann>
what'd be cool:
<tabemann>
history
<tabemann>
line editing (think readline)
<tabemann>
loading data from files (including recursively, think #include, #require)
<crest>
like e4thcom?
<tabemann>
yeah, but better line editing that e4thcom
<crest>
i never got e4thcom working properly for mecrisp-st
<crest>
but i attempted to use the freebsd linux abi
<crest>
to run e4thcom on freebsd instead of linux
<tabemann>
I use e4thcom on linux for zeptoforth in noforth mode
<tabemann>
my main gripe about e4thcom is that it has as low limit on the lengths of paths entered or the depth of history
<crest>
would it be useful to reset the microcontroller through the stlink even if it gets stuck on BEGIN AGAIN
<tabemann>
yes
<tabemann>
to avoid wearing out the reset button on the board
<crest>
and riping out wires on breadboards
<crest>
on the way to the reset button
<crest>
the padding requirements for fast transfers are annoying
<tabemann>
but considering that you can get much better performance than serial, from what it seems, I'd say it's worth it
<crest>
sure
<crest>
did you take a look at my first prototype?
<crest>
it was as fast a 115200 baud serial for most things
<crest>
for each direction (rx, tx) there is a single byte buffer and a flag
<crest>
one flag is negated so make the start value for the 32bit word all zeroes
<crest>
you could add : init swd-init ; to set the console one automatically
<crest>
the host has to know the memory address and just polls it with a single 32bit read
<crest>
the bytes can be changed atomically with 8bit writes
<tabemann>
cool
<crest>
which allows this naturally aligned 32bit word act as two 1 byte ring buffers
<crest>
this results in ping-pong processing between the forth and terminal program
<crest>
and pc hardware, firmware and software aren't optimized for low latency
<crest>
my second design uses a rather large 256 byte ring buffer per direction
<crest>
yes this uses 512 + 4 byte sram
<crest>
if it works well i will experiment with smaller buffers
<crest>
until i've found the required queue depth to decouple both well enough
<tabemann>
back
<tabemann>
circular buffers are always a good thing
<tabemann>
I'd say they're one of my most favorite data structures
<crest>
they're a very useful datastructure and it looks like memory model is strong enough to enable their use as single produce, single consumer queues
<tabemann>
cool
<tabemann>
okay, revised my wordlist implementation a bit (combined the RAM and flash orders into a single order), gonna try again to see how it turns out
TCZ has quit [Quit: Leaving]
<crest>
do you support forgetram?
<tabemann>
just reboot
<tabemann>
which is equivalent aside from that it resets the hardware too
<crest>
i have a working interactive console
<tabemann>
I could implement forgetram though
<tabemann>
the irony is that I effectively had a working forgetram in the past, but got rid of it
<tabemann>
I called it "reboot"
<crest>
why?
<crest>
(get rid of it)
<tabemann>
because I was having trouble with the fact that it wasn't resetting the hardware
<tabemann>
it'd restart, and re-call init, but because the hardware wasn't reset it'd get confused and cause the board to lock up
<crest>
why can't they just use a simple 64bit or 128bit int
<crest>
macos even includes time operating on 64bit floating point numbers containing the seconds since unix epoch
<crest>
*time operations
<tabemann>
that's because not all archs can be relied upon to have a 64bit or especially a 128bit int
<crest>
name one unix without a 64bit integer type
<tabemann>
I wouldn't know offhand
<crest>
and one 64bit unix without a 128bit type hidden somewhere in the compiler
<crest>
both gcc and clang have 128 bit int support on all 64bit platforms i've encountered
<tabemann>
128bit ints are typically only available for archs that have 64bit words natively
<veltas>
tabemann: "I personally don't care about it much; I just implement forth as fits my purposes" can't argue with that approach
<veltas>
Measuring time on a computer is usually a multifaceted approach
<tabemann>
especially on an OS like linux
<tabemann>
like when programming with linux I like monotonic time, even though it doesn't match the wall-clock time
<tabemann>
because it can be guaranteed to always increase, never decrease
<tabemann>
unlike real-time time
<crest>
veltas: that's why there are multiple clocks
<crest>
in this case i care about the uptime clock
<crest>
i want to reduce the polling frequency depending activity
<crest>
both linux and freebsd implement clock_gettime(CLOCK_UPTIME_FAST) with a vdso
<crest>
so reading the uptime on each polling itteration doesn't add any syscalls to the loop
<tabemann>
oh, so the kernel periodically updates a register in userspace with the uptime?
<crest>
no
<tabemann>
so you can access it without the overhead of an extra system call?
<crest>
the kernel maps a page with various useful information into the process addressspace
<tabemann>
of course
<crest>
at least one per process and a global one
<crest>
the global one contains things like clocks and offsets to them
<crest>
the per process one includes the process id and a few other things
<crest>
the kernel updates the shared memory as often enough
<veltas>
tabemann: I'm using a circular buffer to save keyboard input on my forth
<crest>
this is cheaper than using syscalls to read the data
<tabemann>
yeah
<tabemann>
veltas: I'm using circular buffers to buffer serial input and output in zeptoforth
<veltas>
Well we are using them for sort of the same things then
<tabemann>
this is for an intermediate state between their being received or sent and their actual consumption
<veltas>
Yeah in my forth you receive keyboard input from the circular buffer with EKEY
<veltas>
There is no waiting for output though, straight to the screen it goes
<tabemann>
this was buffering so that more data could be received or sent per USART interrupt
<tabemann>
making things more efficient and reducing the chance of lost data
<veltas>
Yep same reason here
<veltas>
Different interrupt
<veltas>
Mine is because otherwise you could literally miss a key press
<veltas>
I have a 32-bit uptime counter that gets incremented every 20ms, during an interrupt, and that also calls the keyboard scanning routine that buffers keypresses
<veltas>
It occurs just before every frame, that's the only interrupt I have to work with
<tabemann>
yeah, the interrupt I'm using is trigerred by input or being ready for output
<tabemann>
*triggered
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
cmtptr_ is now known as cmtptr
TCZ has joined #forth
dys has quit [Ping timeout: 256 seconds]
gravicappa has quit [Ping timeout: 256 seconds]
xek_ has quit [Ping timeout: 256 seconds]
<crest>
tp: the basic interactive usage works
<crest>
next step: cleanup and refactoring
TCZ has quit [Quit: Leaving]
<tp>
crest, awesome news, I'll have to try it myself
<crest>
tp: after that i want to add file upload
<tp>
crest, yours is the first 'new thing' I've seen for Mecrisp-Stellaris
<crest>
performance is good but i haven't measured it yet
<crest>
for a fair comparison i would have to add similar sized ringbuffers to the serial
<crest>
but i don't care about fairness :-P
<tp>
crest, to hell with fairness, may the best system win!
<crest>
the best system could be uart with ack/nak and buffering
<crest>
i added an adaptive poll rate to the terminal program
jackdaniel has quit [*.net *.split]
Vedran has quit [*.net *.split]
jhei has quit [*.net *.split]
jhei has joined #forth
jackdaniel has joined #forth
Vedran has joined #forth
<crest>
if nothing has been transfered in a while it adds a usleep()
<tp>
crest, what about hardware handshaking, that's very fast and why I use it ?
MrMobius has quit [*.net *.split]
deesix has quit [*.net *.split]
lonjil2 has quit [*.net *.split]
Chobbes has quit [*.net *.split]
WilhelmVonWeiner has quit [*.net *.split]
WilhelmVonWeiner has joined #forth
deesix has joined #forth
Chobbes has joined #forth
lonjil2 has joined #forth
MrMobius has joined #forth
<crest>
hardware handshaking needs more pins
MrMobius has quit [Max SendQ exceeded]
<tp>
crest, thats not a problem
jimt[m] has quit [*.net *.split]
siraben has quit [*.net *.split]
<tp>
crest, we live in a age where mcus have up to 180 pins
jimt[m] has joined #forth
siraben has joined #forth
<crest>
no but having just data, clock and gnd is nice
siraben has quit [Max SendQ exceeded]
<tp>
'nice' doesnt win, 'best' wins
jimt[m] has quit [Ping timeout: 252 seconds]
<crest>
and ack/nak solves other problems as well (stop on first error)
Blue_flame has quit [Ping timeout: 246 seconds]
<crest>
"good enough" wins
MrMobius has joined #forth
Keshl has quit [*.net *.split]
Keshl has joined #forth
proteus-guy has quit [*.net *.split]
phadthai has quit [*.net *.split]
diginet2 has quit [*.net *.split]
veltas has quit [*.net *.split]
fiddlerwoaroof has quit [*.net *.split]
clog has quit [*.net *.split]
clog has joined #forth
veltas has joined #forth
phadthai has joined #forth
proteus-guy has joined #forth
fiddlerwoaroof has joined #forth
diginet2 has joined #forth
<tp>
not at the races :)
<tp>
it's interesting how software people see software as a solution and hardware people see hardware as a solution
<crest>
hardware flow control solves on problem perfectly
<crest>
it's just that there are other problems that need solving as well
<tp>
yes, lots of problems to solve
<crest>
unless you want to add an other pin for compiler errors
<crest>
at that point why not use a parallel data bus to upload programs?
<crest>
scnr
<tp>
probably because serial is fast enough for me
<tp>
if serial wasnt fast enuf, I probably would look at serial
<tp>
I'm using a 32 pin mcu, so at some point the number of pins is a issue
<tp>
the mcu is tiny tho, 5x5x1.2 mm in size
dave0 has joined #forth
siraben has joined #forth
jimt[m] has joined #forth
<crest>
seems like my ring buffer size isn't excessive
<crest>
executing words reached a queue depth of at least 216
<crest>
i really hoped to reduce the sram consumption without reduction in throughput
<crest>
.oO( does how hard would it be to write a firmware that speaks usb modem to the pc and swd to the blue pill? )
<crest>
s/does//
<tp>
so modem for rx and swd for tx ?
<crest>
to use an other stm32 (or even the one on those stlinkv2 clones)
<crest>
and replace its firmware
<tp>
we have a forth usb driver for the blue pill, I use it in my diags binary (300 downloads)
<crest>
i know i managed to cobble something together from the old embello code that works on mecrisp stellaris 2.5.3
<tp>
if you replace the fw on a stlinkv2 clone youll probably need to solder some wires to it
<crest>
sure
<crest>
and i would have to come up with a way to set the memory address
<tp>
so use another stm32 to do what exactly ?
<crest>
either inband signaling or an other usb endpoint
<crest>
to just act like a generic usb modem to the host
<crest>
and poll the ringbuffer via swd
reepca has joined #forth
<tp>
why not just use a usb-3.3v serial dongle like I do ?
<crest>
instead of going through the libstlink -> libusb -> usb -> stlink firmware -> swd
<tp>
I like the idea of not needing software on the pc
<tp>
especially as IM looking at openindiana as a os for my workstation atm
<crest>
do you want to play with my fast prototype?
<tp>
ahh I see, usb to the 'dongle' and swd from the dongle to the stm32 target ... I like it
<tp>
sure
<crest>
do you have a freebsd system, a blue pill, a usb serial adapter and stlinkv2?
<tp>
yes
<tp>
FreeBSD gronk 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb 5 15:30:36 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
<crest>
that system is end of life but okay
<tp>
it's a bit old but about to upgrade, problem is it's still too damn useful
<crest>
lets hope pkg install -y stlink works
<crest>
or do you have it already installed?
<tp>
past end of life actually, but that doesnt stop it working
<tp>
I already have stlink installed
<crest>
ok
<tp>
I use it all the time
<tp>
have for years
<tp>
it may jump from FreeBSD 11.2 to openindiana tho
<crest>
why?
<tp>
but if that happens I'll keep a freebsd 12.1 around on a small pc anyway