<tabemann>
CREATE is failing - and when I put instrumentation code in - it fails really weirdly
<tabemann>
in that when I comment out all the code that could have failed other than the instrumentation code
<tabemann>
it still fails
<tabemann>
also, it fails differently from how it failed before I added the instrumentation code
<tabemann>
and mind you all the instrumentation code is is: space ." a" ... space ." b" ... space ." c" ... etc
<tp>
hate that
<tp>
I sometimes get similar results when debugging, but not often
<tabemann>
lolol
<tabemann>
I wrote out the exact code that was failing, with the "real" code commented out, in one line and without comments, and to RAM
<tabemann>
and it works!
<tp>
sometime one must do the debugging mentally
<tp>
I finally finished working out what various C codes do to make touch sensing work
<tabemann>
well well well
<tabemann>
I took the exact some code that worked in RAM
<tp>
and ...
<tabemann>
and compiled it to flash
<tabemann>
it failed!
<tp>
I'm not surprised
<tp>
if I try creating a array in flash, it fails too
<tp>
but is fine in ram
<tabemann>
this is just compiling
<tabemann>
nothing like allocating space
<tabemann>
and furthermore I wrote a layer that makes working with flash vis-a-vis ram as simple as possible
<tp>
as you do
<tp>
i have hflash! and erase etc
<tp>
all Forth words of course
proteusguy has joined #forth
<tabemann>
okay
<tabemann>
I found it also crashes sometimes under ram compilation and execution
<tabemann>
hey proteusguy
<tabemann>
something is corrupting the string literals it's compiling
<tp>
hence the bif fail above ?
<tp>
big
<tabemann>
okay, it only fails if "token" is in the word
<tabemann>
token being my word to parse a single token from the input stream
<tabemann>
really f*cking odd bug
<tp>
no active fires today brings to an end more than 240 days of continuous fire activity where I live
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tabemann>
I'm confused; I now remove token altogether, and it still fails
<tabemann>
it seems like australia is always on fire
<tp>
yeah pretty much
<tp>
way of life here
<tp>
tabemann, does zapyou forth represent the most debugging youve done in a while ?
<tabemann>
zeptoforth
<tp>
sorry ;-)
<tabemann>
I'm always doing debugging when bringing up a forth (this is my third one), and I do a lot of debugging at work
<tabemann>
(the first was an overengineered attempt at a POSIX forth, the second was an attempt at a POSIX forth that was implemented as much in Forth or VM assembly as possible, and this is a Cortex-M assembly Forth)
<tp>
nice
<tabemann>
the second forth was really nice actually
<tabemann>
it had support for trapping signals
<tabemann>
and backtraces
<tabemann>
and it could dump the contents of words
<tabemann>
it was originally cooperative multitasking, but I added optional preemptive multitasking
<tabemann>
I implemented a variety of data structures and inter-thread communication constructs
<tabemann>
it was kinda slow though
<tabemann>
since it was token-threaded
jfe has joined #forth
jfe has quit [Remote host closed the connection]
jfe has joined #forth
jfe has quit [Ping timeout: 255 seconds]
<tabemann>
okay, gotta go - coffee shop is closing
<tp>
cya, me too
<tp>
bbl
tabemann has quit [Ping timeout: 260 seconds]
jfe has joined #forth
iyzsong- has joined #forth
iyzsong has quit [Ping timeout: 272 seconds]
tabemann has joined #forth
WickedShell has quit [Remote host closed the connection]
<veltas>
How do forths typically deal with assembly label support?
<veltas>
My current idea is to have words "LABEL" and "REF", and assembly that consumes a ref with no defined label will add a reference entry to a table that will link it all up at the end
<john_cephalopoda>
veltas: That's one way to do it. The other way is to have two passes. In the first pass you assemble your code and store the label addresses in label variables. Then you do a second pass where you do the same thing, but this time you're able to use the actual addresses.
<veltas>
That was another way I considered doing it
<veltas>
But I was not sure how to not actually store two copies while doing that
<veltas>
Well I mean without changing too much code
<veltas>
I am actually getting a little turned off by how restrictive my Forth assembly stuff is so I'm going to focus on writing my Forth in an assembly language first
<veltas>
I'll worry about self-hosting later
<veltas>
I hope that doesn't horrify anyone
jfe has joined #forth
jfe has quit [Ping timeout: 265 seconds]
Monev has joined #forth
Kumool has quit [Read error: Connection reset by peer]
jfe has joined #forth
_whitelogger has joined #forth
john_cephalopoda has joined #forth
john_cephalopoda has quit [Ping timeout: 260 seconds]
<tp>
veltas, the Forth I use is written in assembly and cross compiled. I don't see how a Forth for a small embedded MCU can be self-hosting anyway ?
jfe has quit [Ping timeout: 255 seconds]
<john_cephalopoda>
tp: You could write an assembler in Forth. As long as you got an fs driver (SD card), self-hosting shouldn't be an issue. Assuming you got enough memory to run it all. It would get quite complicated to pull of on some tiny AVR thing.
<veltas>
tp: I plan to implement blocks or files using tapes
<veltas>
We'll see lol
<veltas>
I am, by the way, writing for the ZX Spectrum
<tp>
john_cephalopoda, I think it would be quite impossible on a small device such as the one I use all the time. It only has 64kB of flash and 8 Kb of ram
<veltas>
Yeah I have 48K of RAM
<veltas>
'Plenty' of room
<tp>
i'm not a real programmer, Im a electronics tech, but I get the impression that 'self-hosting' forths are the domain of the PC ?
<veltas>
The ZX Spectrum is a PC
<veltas>
I hope to be able to build my forth within its own environment, I really like that idea, long way off knowing if even feasible
<veltas>
"not a real programmer" most often said by the real(TM) programmers ;)
<tp>
veltas, hahah, so people say but I barely know the terminology of programmers and do on, I'm a Forth user really
<tp>
i just use Forth to make devices, before that I used C
<veltas>
C is a real language IMO
<tp>
I can see the point of a self-hosting tethered Forth such as the one rdrop-exit is building, as that lives on a PC
<tp>
but a PC has literally tons of resources
<tp>
unlike a small mcu such as mine
<tp>
your ZX has a Z80 cpu which in itself has no resources
<john_cephalopoda>
I am using RETRO Forth, which I can run on x86 with a ~2K VM and a 54K VM image file. That image file can probably be downsized.
<tp>
so your ZX is more like a PC, but of course limited to the Z80 address capacity whick is 64k iirc
<veltas>
Yeah I have 48K RAM, and about 6K are eaten up by the framebuffer
<tp>
john_cephalopoda, which is pretty amazing, I am more and more impressed by Retro
<veltas>
Only 32K runs without the CPU being underclocked to avoid contention with the ULA accessing framebuffer to draw the screen
<veltas>
john_cephalopoda: Did you write RETRO?
<john_cephalopoda>
veltas: No, it's written by crc.
<veltas>
Oh right I feel like I should know this
<veltas>
I think I was reading its source the other day
<john_cephalopoda>
I wrote an implementation of the underlying VM in an assembly language written in RETRO though.
<john_cephalopoda>
tp: Those 52K are actually quite big. They contain tons of words for array processing and similar, which I never use.
<tp>
john_cephalopoda, I see
<tp>
john_cephalopoda, the Forth I use on my 64Kb flash/8kb ram has a ton of Words and fits in 19kb, uses 2kB ram
<tp>
which is about right for a useful self contained Forth
<tp>
oh WOW. I had just abandoned a project I have been working on for about 4 days, even said so in the last commit as I felt the hardware and tech design was dodgy, then I just now decided to change one component as a final effort ans it's working!
<tp>
amazing
<tp>
detection value without a finger on the sensor = 5454 plus or minus 10
jfe has joined #forth
<tp>
detection with a finger on the sensor = 518 plus or minus 18
<tp>
thats a excellent signal to noise ratio!
<john_cephalopoda>
veltas: Developing for ZX Spectrum sounds like a very cool project. I've never done anything with retro-computing before, but I always found it interesting.