MrMobius has quit [Read error: Connection reset by peer]
jsoft has joined #forth
iyzsong has joined #forth
jsoft has quit [Ping timeout: 256 seconds]
dave0 has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
MrMobius has joined #forth
dys has quit [Ping timeout: 268 seconds]
<tabemann>
tp: I just realized a problem with e4thcom
dave0 has quit [Quit: dave's not here]
gravicappa has joined #forth
<tp>
tabemann, ?
<tp>
tabemann, the only problem I found with e4thcom is that it only ran on Linux
<tabemann>
the issue I've found is it sends data too fast
<tabemann>
it's fine when I'm handling input without a multitasker
<tabemann>
but with the multitasker I've had to hack in special IO code so it can keep up
<tp>
oh
<tabemann>
i.e. code which buffers all input it can get on every PAUSE
<tabemann>
it seems to work with a buffer of 16 characters
<tp>
I dont understand, I didnt have that problem and I used it for several months
<tabemann>
the problem is it was reading input too slowly
<tabemann>
another solution would be to use an ISR to handle reading input
<tabemann>
it seems to work okay now
<tabemann>
at least with three tasks (main and two others)
<tp>
I know e4thcom must read input slower then other serial terminals as it has to examine the data to remove comments etc
<tp>
but are you saying it sends data faster than the configured baudrate ?
<tabemann>
tp bursts data all at once
<tabemann>
I think it sends data as fast as it can at a given baudrate
<tp>
dont they all ?
<tabemann>
but if the code on the MCU doesn't keep up, data is lost
<tp>
you mean if the usart buffer is overrun ?
<tp>
if the target mcu buffer is overun thats the only time i have problems
<tabemann>
yes, because the software isn't reading data from the USART fast enough
<tp>
have you tried e4thcom with Mecrisp-Stellaris ?
<tabemann>
the strategy I've come up with is to read a full (software) buffer of data at once, and then allow a given task to read data from that buffer as fast as possible
<tabemann>
I have
<tabemann>
but not with a multitasker
<tp>
in fact one reason I sent to Screen was that e4thcom has a max baudrate od 115200 baud, in my case e4thcom was too *slow*
<tabemann>
likewise, I've only gotten issues when using a multitasker with zeptoforth
<tp>
ah ok
<tp>
my does a multitasker make any difference ?
<tp>
my = why
<tp>
I did my last prokect with a multitasker
<tabemann>
because it makes the time between characters read longer for a naive implementation
<tabemann>
so it increase the chances that the software won't keep up with the USART buffer
<tabemann>
whereas without one
<tabemann>
the refill routine can read as fast as it can
<tabemann>
because it doesn't have to share time with any other tasks
<tp>
ahh
<tp>
wow, the things doing a new cortex-m Forth turns up!
<tabemann>
one thing that annoys me is that code compiled to flash does take up a lot of space
<tp>
I was reading a article about someone using Mecrisp-Stellaris with freertos where Forth is run in it's own task
<tp>
more space than ram ?
<tabemann>
like with the kernel, the basic compiled code, and the multitasker, it takes up $9800 space
<tabemann>
mind you this is with cornerstones
<tp>
under 10k not bad
<tabemann>
with cornerstones removed it's $8CE0
<tabemann>
that's in hex
<tp>
I have stopped using the multitasker because I only really wanted a simple scheduler
<tabemann>
it's 35K in size
<tabemann>
which feels... large to me
<tp>
I cant relate hex to binary
<tp>
intelhex I mean
<tabemann>
the kernel is 24K in size
<tabemann>
so just he basic Forth words plus the multitasker is 11K in size
<tp>
you can easily convert ihex to binary with gcc i think
<tp>
oh!
<tp>
I see
<tp>
the kernel is 24k of binary ?
<tabemann>
yes
<tabemann>
the thing is the kernel does far, far more than twice of what the extras do
<tp>
well it's for a cortex-m4 and they have tons of flash
<tabemann>
I know, but it feels like the extras don't do that much in comparison
<tabemann>
they're mostly basic routines missing from the kernel and a multitasker
<tp>
a CircuitPython binary needs a minimum 256k
<tabemann>
okay, just the basic extras take 4K when compiled to RAM
<tabemann>
and less than that, because I didn't take into account the extra variables at the base of RAM
<tabemann>
okay, the basic extras are also 4K when compiled to flash
<tp>
as youd know the Mecrisp-Stellaris binary for all the variants is about 20.5kB for the RA version, so I guess thats the lower level for cortex-m forths ?
<tp>
plus Mecrisp-Stellaris has a lot of inbuilt words
<tp>
I must compile a kernel only version of Mecrisp-Stellaris and see what size it is
<tabemann>
the zeptoforth kernel lacks a lot of things, and isn't register-assigning
<tp>
the other thing is that all the Mecrisp-Stellaris Words are in assembler, and theyre hand optimised
<tabemann>
note that it could be denser, e.g. it contains a partial assembler which is used in many places where just hard-coded instructions could be used
<tp>
the Mecrisp-Stellaris assembler isnt 100% complete either
<tabemann>
that's what the basic extras are for, for adding things like TRUE, FALSE, CREATE, <BUILDS, DOES>, flash-definable RAM variables, and so on
<tp>
flash-definable RAM variables!
<tabemann>
one advantage of zeptoforth over mecrisp-stellaris AFAIK is that you can easily define RAM variables from flash, even though you have to reboot before you can use them
<tp>
thats true, Mecrisp-Stellaris cant create ram variables from flash
<tp>
but Mecrisp-Stellaris does create buffers from flash
<tp>
which is what everyone uses
<tp>
oops
<tabemann>
you can also create buffers from flash too
<tp>
Mecrisp-Stellaris does create variables from flash
<tp>
doh!
<tp>
theyre just specified in the source thats uploaded to flash
<tp>
ie "0 variable FOO"
<tp>
and Mecrisp-Stellaris does something to make that work
<tp>
but I guess the correct description is that "when running from flash, new variables cant be created" ?
<tabemann>
how I do them is as follows: for each ram varialbe defined from flash, I create a word named *RAM* containing the offset for the next ram variable
<tabemann>
and then at boot time it looks up the last defined instance of *RAM* to fetch the offset of HERE
<tp>
hmm, you made me realise that variables created live only run in ram
<tp>
and that those same variables are only created created when 'compiled' to flash after a reboot and a 'compile to flash' for everything
<tabemann>
rebooting is necessary because space needs to be allocated for them before any other space is allocated
<tp>
that makes sense
dddddd has quit [Ping timeout: 240 seconds]
<tabemann>
well, multitasking seems to now work properly, with it taking up less memory footprint now that I have optimized the size of the fields used for the multitasking control data
<tabemann>
except I haven't yet tested task exiting, which was broken last time I checked
<tp>
you save all the registers I guess ?
<tp>
and restore them ?
<tp>
or the main ones anyway
<tabemann>
no
<tabemann>
the only registers I save are r6, r7, and sp
_whitelogger has joined #forth
<tp>
cool
<tabemann>
it was the stupidest of bugs - I had made a mistake in the implementation of ?dup of all things
iyzsong has quit [Ping timeout: 272 seconds]
<tabemann>
okay, I should get to bed
<tabemann>
g'night
gravicappa has quit [Ping timeout: 256 seconds]
iyzsong has joined #forth
<tp>
nighto
_whitelogger has joined #forth
_whitelogger has joined #forth
gravicappa has joined #forth
jsoft has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
dave0 has joined #forth
actuallybatman has quit [Ping timeout: 260 seconds]
_whitelogger has joined #forth
iyzsong has quit [Ping timeout: 240 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
siraben has quit [Ping timeout: 245 seconds]
siraben has joined #forth
dddddd has joined #forth
gravicappa has quit [Ping timeout: 265 seconds]
jsoft has quit [Ping timeout: 255 seconds]
xek has joined #forth
proteus-guy has joined #forth
dave0 has quit [Quit: dave's not here]
TwoNotes has joined #forth
TwoNotes has quit [Remote host closed the connection]
actuallybatman has joined #forth
Mellowlink has joined #forth
<Mellowlink>
hello, I'd like to use forth instead of assembly for my future projects. I got gforth from my distro repo but I didn't find in documentation instructions how to generate a binary object from code.
<Mellowlink>
is there any way how to do that please or is gforth only a real time interpretation?
<veltas>
I had been designing an embeddable language based on Lua for the Spectrum and then I found Forth and it seems like a much better fit
<veltas>
ZX Spectrum that is
<veltas>
I just don't know how usable the result will be, originally I was going to have syntax not completely different to Python
<veltas>
I don't have a clear idea of the target audience, so right now Forth or something that fundamentally works very similarly to Forth seems worth trying
gravicappa has joined #forth
mtsd has joined #forth
koisoke_ has quit [*.net *.split]
koisoke has joined #forth
rpcope has quit [*.net *.split]
rpcope has joined #forth
mtsd has quit [Quit: Leaving]
gravicappa has quit [Ping timeout: 256 seconds]
tp has quit [Read error: Connection reset by peer]