<KipIngram>
You bet. It's an interesting feature of the language, and is an important part of being able to inject pretty much arbitrary syntax into your application.
<KipIngram>
The CREATE part will be very similar to what I called out - that' where the memory actually gets allocated. The DOES> part specifies what the word does when it's executed, so you put your address calculation there.
spoofer has joined #forth
<WQX>
can i also read and write numbers from a txt or csv file using forth?
<KipIngram>
Almost all Forths will give you a way to do this, but it system dependent. When it was first created Forth didn't run under any operating system - it ran as the bare metal software of the system, and it managed disk space in a different way. As Forths have been implemented to run under OS supervision later on, each one has generally provided some sort of file access tools. I'm sure GForth has this, but I'm
<KipIngram>
not familiar with the details.
<KipIngram>
You'll find GForth offers a way to do practically anything.
<KipIngram>
It's sort of a "kitchen sink" Forth.
<KipIngram>
Out of curiosity, what is your application, WQX? Forth is not really the first language that comes to mind for manipulating floating point matrices and vectors and accessing text files. :-)
<WQX>
KipIngram: I agree, I wanted to implement an algorithm to calculate the inverse of a matrix, I work a lot with numerical methods and computational mathematics, in fact I found the language interesting and wanted to learn a little more about it and try to apply the forth in this area. I heard it said that the forth has the advantage of having an excellent performance and so I might be able to gain a certain performance in my calculations.
<WQX>
I apologize for my horrible English, I don't speak English very well
<tabemann>
umm, you're probably better off working in Julia
<tabemann>
if you want to do that kind of thing, Julia is what I'd suggest TBH
<tabemann>
(Julia is kind of what'd you get if you crossed Python with Fortran)
<tabemann>
(and made Common Lisp be the godparent)
<tabemann>
about Forth, Forth is better for applications where direct access to the hardware is needed
<tabemann>
yes, KipIngram was talking about OS-hosted Forths like gforth
<tabemann>
but Forth is particularly excellent for embedded applications
<tabemann>
WQX
<WQX>
tabemann: but what about performance? forth has a greater speed than julia right?
<tabemann>
gforth is approximately 20% as fast as C
<tabemann>
Julia is basically one of the fastest high level languages there are
<tabemann>
note that Julia is compiled to native code at runtime
<tabemann>
traditionally Forths use something called "indirect threading" which, TBH, is quite slow, but some newer Forths such as Mecrisp-Stellaris and my zeptoforth (shameless plug) compile directly to native code
<tabemann>
just checked, and gforth uses either direct-threading/indirect-threading hybrid or plain indirect-threading depending on how one configures it
<tabemann>
whereas Mecrisp-Stellaris and my zeptoforth are subroutine threading/native code inlining
<tabemann>
they're still slower than C, though, due to the need to juggle the stack around
<WQX>
"tabemann: gforth is approximately 20% as fast as C" that's what motivated me to study forth, I tried to study using Julian V. Noble's book (Scientific Forth, 1992), but the version of forth that is used in the book is quite different from gforth
<WQX>
sorry, but what is TBH?
<tabemann>
my recommendation if you want to use Forth is to build up a layer of primitives on which one can build one's code
<tabemann>
TBH = to be honest
<KipIngram>
WQX: Forth is unlikely to exceed the speed of C or a similar language in a calculation like that. And I suspect you won't find any extensive numeric libraries in Forth, so you will have to implement your own algorithms. But it sounds like that may be what you want to do anywy.
<WQX>
tabemann: but in this case, comparing the performance c, gforth, julia, which one would be the fastest?
<KipIngram>
I would expect C to be the fastest. But it's hard to say, because often in a language like Julia the actual numerical routines in a library may be C based. That's often the case in Python.
<WQX>
"KipIngram: WQX: Forth is unlikely to exceed the speed of C or a similar language in a calculation like that. And I suspect you won't find any extensive numeric libraries in Forth, so you will have to implement your own algorithms. But it sounds like that may be what you want to do anywy." yes
<KipIngram>
The language itself won't keep up with C at all, but the numpy library used in Python has huge C content, so once you call a compute intensive algorithm like, say, LU factorization you're then basically running C.
<KipIngram>
So if your code spends like 99% of its time in those numeric libraries, then overall the speed difference between C and Python can become negligible.
<KipIngram>
But if you are writing your own algorithms then you'd never want to write them in Python if you're interested in performance.
<KipIngram>
Forth is very high performance for an interactive language.
<KipIngram>
You can't really sit down and just "type C" at a computer, but you can sit down and type Forth at it.
<tabemann>
back
<tabemann>
Julia is faster than Python, but Python probably has more extensive numerics libraries than Julia
<tabemann>
(Python is interpreted, while Julia is compiled to native code at runtime)
<tabemann>
but as KipIngram says, that doesn't matter
<tabemann>
because your numerics libraries will almost certainly written in C whether you're using Python or Julia
<tabemann>
*be written
<tabemann>
if you opt for Forth, you'll certainly have less performance than C numerics libraries called from Python or Julia
<tabemann>
furthermore, you'll have to do all the work of writing everything by yourself
<WQX>
truth
tech_exorcist has quit [Quit: tech_exorcist]
<WQX>
KipIngram & tabemann: I thank you very much for clarifying my doubts, you helped a lot
<KipIngram>
Good luck with your work, WQX.
boru` has joined #forth
boru` is now known as boru
<WQX>
KipIngram: thanks
Zarutian_HTC has quit [Ping timeout: 260 seconds]
Zarutian_HTC has joined #forth
<MrMobius>
isnt there some kind of interpretted C repl out there? I remember hearing about this once
<MrMobius>
cint maybe
<tabemann>
I would assume that some kind of interpreted C repl'd almost certainly be slower than a Forth REPL
<tabemann>
because a Forth REPL is like as simple a REPL as you can get
WQX has left #forth [#forth]
dsmcfarl has joined #forth
<KipIngram>
I'd think so too.
<MrMobius>
hmm maybe so. i think cint is all interpretted anyway so not fast to begin with
sts-q has quit [Ping timeout: 240 seconds]
sts-q has joined #forth
<KipIngram>
But it could still be good to use in the early phases of developing something.
<KipIngram>
I've come to believe that one of Forth's advantages is that heavy factoring has low function call overhead. You can factor factor factor in C too, but you get parameter passing overhead at every stage. With Forth there's just the call and the return, and nothing else.
<KipIngram>
Though I guess you could structure an app using global variables.
<KipIngram>
And not have parameters.
Zarutian_HTC has quit [Ping timeout: 240 seconds]
<remexre>
depending on your (micro)architecture C can suck less at this too though; afaik, the aarch64 ABI on a CPU with reg renaming and a deep enough return addr prediction stack makes factoring pretty cheap
<remexre>
largely because they make the imo very reasonable choice to make returns and params the same, and because aarch64 can load/store two registers per instruction
Zarutian_HTC has joined #forth
<KipIngram>
That sounds reasonable. I don't really know exactly what the overhead is. It just seemed to me that having to build a big stack frame for a function call, only to have that function do the same thing again after a very small amount of code, would get slow on you. But it seems like there should be ways to avoid that.
<KipIngram>
When I was playing with a Forth processor in an FPGA, I managed to get it setup so that the returns were free (in terms of time).
<KipIngram>
I never actually built and ran that, though - it was only on paper.
<KipIngram>
But I had the hardware stack and the 32 opcodes encoded and implemented so that there were only two gate delays between flip flop output and flip flop input.
<KipIngram>
It should have easily managed 100 MHz.
<KipIngram>
Maybe 150.
jedb_ has joined #forth
jedb__ has joined #forth
jedb_ has quit [Ping timeout: 240 seconds]
kiedtl has quit [*.net *.split]
jedb__ has quit [*.net *.split]
siraben has quit [*.net *.split]
dnm has quit [*.net *.split]
Zarutian_HTC has quit [*.net *.split]
jimt[m] has quit [*.net *.split]
ovf has quit [*.net *.split]
MrMobius has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
jedb__ has joined #forth
siraben has joined #forth
pareidolia has joined #forth
ovf has joined #forth
rpcope has joined #forth
mark4 has joined #forth
dys has joined #forth
KipIngram has joined #forth
a3f has joined #forth
dnm has joined #forth
mjl has joined #forth
krjt has joined #forth
Zarutian_HTC has joined #forth
Lord_Nightmare has joined #forth
jimt[m] has joined #forth
kiedtl has joined #forth
jn__ has joined #forth
nitrix has joined #forth
mstevens has joined #forth
lonjil has joined #forth
tabemann has joined #forth
klys has joined #forth
Keshl has joined #forth
fiddlerwoaroof has joined #forth
APic has joined #forth
MrMobius has joined #forth
swineflu has joined #forth
siraben has quit [Max SendQ exceeded]
rann has quit [Ping timeout: 245 seconds]
ovf has quit [Ping timeout: 245 seconds]
sts-q has quit [Ping timeout: 240 seconds]
jimt[m] has quit [Ping timeout: 245 seconds]
rann has joined #forth
ovf has joined #forth
sts-q has joined #forth
gravicappa has joined #forth
siraben has joined #forth
jimt[m] has joined #forth
f-a has joined #forth
dave0 has joined #forth
<dave0>
maw
<KipIngram>
Evening, dave0.
<dave0>
hi KipIngram
dave0 has quit [Quit: dave's not here]
dave0 has joined #forth
<dave0>
maw
clog has quit [Ping timeout: 276 seconds]
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
andrei-n has joined #forth
<veltas>
"could someone tell me how do i declare an matrix of floating points using gforth?"
<veltas>
I kind of wish I was watching the channel so I could have answered that question
tech_exorcist has joined #forth
tech_exorcist has quit [Ping timeout: 265 seconds]
<veltas>
It is a big whole that there is no FCREATE or F, though
<veltas>
It's impossible to create a floating-aligned parallel for CREATE in purely standard forth
<veltas>
Big hole*
<veltas>
A parallel would require the following: HERE starts floating-aligned, body is HERE after running FCREATE, DOES> works with it as expected
Zarutian_HTC has quit [Ping timeout: 240 seconds]
<veltas>
It's totally impossible to do that in standard forth reliably, the only way is to run CREATE repeatedly until it's floating-aligned by chance, which could be never depending on the implementation.
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
dave0 has quit [Quit: dave's not here]
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
<KipIngram>
That seems like a severe weakness. You can't do "HERE 7 + 7 AND HERE - ALLOT" to get aligned?
<KipIngram>
I know nothing about "standard" Forth.
<KipIngram>
Oh, wait - sorry.
<KipIngram>
Oh, not that's ok.
<KipIngram>
Thought I'd buggered it.
<KipIngram>
I'm not sure I got it quite right, you I think you can see what I have in mind.
<KipIngram>
I have an "align" word in my find, that jumps from the end of the name string to the next 4-byte boundary.
<KipIngram>
Which is where the CFA is.
<KipIngram>
: ALIGN 8 HERE 7 AND - ALLOT ;
<KipIngram>
The standard should certainly provide a word to align to various boundaries. Or the ability to easily create one.
<KipIngram>
I wish you'd been here too - we didn't even think to mention alignment last night. :-(
dsmcfarl is now known as danmc
danmc is now known as dsmcfarl
f-a has quit [Ping timeout: 252 seconds]
_whitelogger has joined #forth
f-a has joined #forth
lchvdlch_ has quit [Ping timeout: 240 seconds]
lchvdlch has joined #forth
lchvdlch has quit [Ping timeout: 252 seconds]
<KipIngram>
You know guys, one project that has come back and teased at my mind again and again is to build a calculator from scratch. Running Forth of course, but both the "embedded guy" in me and the "scientific programming" guy in me salivate over the idea.
<MrMobius>
KipIngram, most of what im doing is building calculators. its really fun!
<veltas>
I have been reading some very old computing manuals recently and they refer to the computers as "electronic calculators" and "expensive calculators"
<veltas>
The floating point words in the standard are not very fleshed out
xek_ has joined #forth
<KipIngram>
One aspect I think would be particularly fun would be to have it support integer finite fields.
<KipIngram>
MrMobius: Thanks for sharing. I've got family visitors in the house, but I'll definitely look it over later.
<KipIngram>
One bit of my background is in seismic, where we sold battery powered wireless recording units, so power conservation and so on is something I'm prepared to pay attention to.
xek has quit [Ping timeout: 265 seconds]
<KipIngram>
MrMobius: one thing you might be able to help me with is where to source keys. I really have no idea how to get something that's really really pleasing as far as a keyboard goes.
<KipIngram>
You too, veltas, if you've got good info on that.
<KipIngram>
I had an HP 41CV back in college, and I just loved that HP key tech that they used back then.
<KipIngram>
So much better than the ones they went to later.
<MrMobius>
KipIngram, keys are probably the most difficult part of the hardware
xek_ has quit [Quit: Leaving]
<KipIngram>
Anyway, I've never seen a calculator (or for that matter a numeric processing system for my computer) that had native support for finite fields.
<KipIngram>
MrMobius: I've looked into it enough for that to become very clear to me. :-(
<MrMobius>
you can get clear plastic caps for 12x12mm switches where you can print the label on paper under the plastic though 12x12mm is much larger than an HP41
<MrMobius>
for one I had a piece of stamp rubber with the labels laser etched in and filled with paint
<KipIngram>
Well, larger might be ok. It would detract from portability, but if I had to sacrifice that a bit I could deal with it.
<MrMobius>
for another one I 3d printed the keys in white then inkject printed the keys in reverse on overhead transparnecy then glued those down so the ink side is glued to the key and your finger never touches it
<MrMobius>
HP's are double shot which I thin is impossible to replicate yourself
<KipIngram>
Whatever it was, it was superb technology.
<MrMobius>
the TIs and Casios I have are all painted on. not sure what kind of paint they use though that withstands years of keypresses
<MrMobius>
another thing ive tried to do is 3d print the keys but you have to keep the text pretty large for that to work. I can do 5mm text on my FDM ender 3
<MrMobius>
which is basically a single letter per key. youd need a big key to accomodate a whole word like "ENTER"
<KipIngram>
Cool. I haven't taken the dive into 3D printing yet, but at some point I'm going to have too. Just too much potential there.
<MrMobius>
the ender 3 is about $200 and is pretty impressive. you can also have things printed and sent to you for pretty cheap
<KipIngram>
I thought about just setting for a touchscreen keyboard, but that's really just a cop-out.
<KipIngram>
settling
<KipIngram>
If I'm going to settle for that I could just write an app for my phone.
<MrMobius>
maybe not if you do it right. a guy gave a presentation where he had a plastic overlay and clear plastic buttons that were raised sitting on top of an LCD with a scissor joint and single button below the LCD
<KipIngram>
I have HP-41CX and HP-42S emulators for my Android, and they're both EXCELLENT.
<KipIngram>
As good as you could ask for. They look perfect - just like the real thing.
<MrMobius>
so when you press any button, the whole LCD depresses slightly and you get the satisfying click. the key labels can then change dynamically
<KipIngram>
And I've confirmed that they use actual HP rom images, because on the 41CX that "synthetic programming" stuff works.
<MrMobius>
hmm ya the problem is though that programming anything on a touchscreen keyboard is horrendous
<KipIngram>
Oh, that's an interesting idea.
<KipIngram>
Those are more than good enough for my casual calculator needs, so if I go down this road I want to include a lot of advanced capabiity you don't normally find on calculators.
<KipIngram>
tensor algebra and calculus, etc.
<MrMobius>
ya I just use the calculator built into android. if you need programmablility which is why you want a 41 or similar then a smart phone is not a good interface
<MrMobius>
unless youre just using pre-existing libraries but even that's gonna suck
<MrMobius>
KipIngram, they already had full CAS for calculus 20+ years ago. you might be surprised how advance they are
<KipIngram>
Perhaps so - I'm just not fully tuned in.
<KipIngram>
Right, and I do want programmability. Forth of course - the one I'm working on now as the foundation. And of course I want to be able to open a terminal window into it on my computer.
<MrMobius>
its pretty interesting. I bought one last year for $39 with a 59mhz CPU and python on board. it has an Xcas port. the more expensive ones have 500mhz ARMs in them with a few hundred mb memory
<KipIngram>
Haven't decided if the source will actually live on the calculator - my job at work has to do with flash-based SSDs, so I know how to deal with those. I could put a stupid amount of storage into the thing if I wanted to, and have it unpowered except when I want to do development.
<MrMobius>
that sounds pretty cool
<KipIngram>
Was that one of those little Cortex M4 dodads?
<MrMobius>
i havent seen one where you can use it over terminal. i think its an awesome idea
<MrMobius>
Numworks?
<KipIngram>
I got one of those, but then not long after my employer turned of write support on my USB ports, so it sits in my drawer gatherinng dust now.
<KipIngram>
Right, I want the full keyboard and screen experience for programming it.
<KipIngram>
I mean, I'd probably have an onboard interface too, but I want the other as well.
<MrMobius>
I like the idea of keeping it plugged into my computer and interacting with it then unplugging it and picking up where i left off when im away from the computer
<KipIngram>
Exactly.
<KipIngram>
So that argues for source onboard. But, like I said - one fat flash chip with power off capability.
<KipIngram>
And whenever it's plugged into power I can run the background sifters you need to keep bit errors down on the flash.
<MrMobius>
wait, you would put an ssd in there?
<KipIngram>
Flash is really crap - if you let it sit on the shelf for a few weeks or months it "forgets."
<KipIngram>
Just one flash chip, like those you might find in an SSD.
<KipIngram>
Not a whole SSD.
<MrMobius>
why not use what everyone else is using to make circuit boards?
<KipIngram>
Not sure what you mean.
<MrMobius>
if you go to a site where you buy components for circuit boards, there are all kinds of flash chips on there
<KipIngram>
Anyway, you need to read through your flash periodically, and if you detect greater than some threshold of bit errors you correct them and write that block to a new home.
<KipIngram>
Those are often NOR flash.
<MrMobius>
which would be perfect for building a device like a calculator and cost almost nothing, so why use something out of an ssd?
<KipIngram>
NAND flash offers more capacity.
<KipIngram>
And it's what I'm familiar with.
<KipIngram>
But sure - I'd need to consider both options.
<KipIngram>
If the NOR units are big enough to satisfy me then they'd be a lot less work to use well.
<MrMobius>
how much space do you need? even the tiniest SD card is probably more than you can use
<KipIngram>
I like to say that our job at the office is to make armor out of tissue paper. Taking this crappy flash and turning it into enterprise-grade data storage gear.
<KipIngram>
Sure - it might be.
<KipIngram>
I'm not making any decisions here today.
f-a has left #forth [#forth]
andrei-n has quit [Read error: Connection reset by peer]
tech_exorcist has quit [Quit: tech_exorcist]
andrei-n has joined #forth
tech_exorcist has joined #forth
Zarutian_HTC has quit [Ping timeout: 240 seconds]
<veltas>
KipIngram: Maybe using NOR *because* you're not familiar with it is a good idea
<veltas>
I would also use NOR on this project
<KipIngram>
:-) Good point. I mean, I understand the basics of how it works. I just don't "saturate myself" in it all the time.
<KipIngram>
NAND is page addressed - the ones we're using currently have pages just over 8k. 8k and a little "extra" to store meta data inn.
<KipIngram>
Cursed 'n' key.
<KipIngram>
Our drives logical page size is 16k. We do hardware compression, so that doesn't necessarily completely fill two pages.
<KipIngram>
So you wind up with logical pages straddling physical pages some percentage of the time.
<KipIngram>
That's the major reason compression improves performance - the higher your compression is, the more often you only need to pull one physical page to get your data.
<KipIngram>
The chips also have a "snap" read feature, where you address a page but only take the lower or upper half of the data.
<KipIngram>
That helps a little too.
<KipIngram>
Addressing time is the same - we just gain the time that would otherwise be spent transferring that data from the chip to the FPGA.
<KipIngram>
It's about 10 us or so.
<MrMobius>
KipIngram, have you seen the forth for arm called mecrisp?
<MrMobius>
it optimizes and outputs machine code for cortex m which is what you would probably use for a calculator
clog has joined #forth
<KipIngram>
No, I don't spend a lot of time perusing other Forths these days.
<KipIngram>
Mostly just play in my own little sandbox.
<KipIngram>
I count on haning out here to make me at least a little aware of "good ideas" that have come along.
<MrMobius>
cool
<MrMobius>
just an idea. you could use that for the firmware instead of C if you wanted
<KipIngram>
I'll keep it in mind. Another thought I'd had for solving the keyboard problem was to perhaps rip the guts out of an existing calculator and replace it. That's kind of limiting though - I'd almost certainly wind up wishing I had other keys on the keyboard. I guess I could try repainting, or use stickers, but I don't know how well that would go.
<MrMobius>
interesting idea
<MrMobius>
if you could repaint or get stickers that wont wear off, you could build your own case
<MrMobius>
which is relatively simple. its just the paint or stickers problem thats so hard to solve
<KipIngram>
Yes.
<KipIngram>
The big problem with this whole project, though, is that honestly I almost never USE a calculator anymore. Most problems that would call for the power of a good programmable I just sit down an flop out in Python.
<MrMobius>
on that note though, there is a project called the WP-34 where HP released the skeleton code for one of their calculators and the community implemented new firmware from scratch that is supposed to be much better
<KipIngram>
I'd need to re-train myself to some degree to actually make it worthwhile to have.
<MrMobius>
there is also one called newRPL where a guy is creating new firmware for the HP-50G which has a 72mhz ARM simulating an old 4mhz calculator CPU. newRPL runs natively on the ARM
<MrMobius>
hehe ya its definitely just a passion project at this point
<MrMobius>
you can also just get a cheap graphing model with python in ROM and youd be set for practical stuff
proteusguy has quit [*.net *.split]
cp- has quit [*.net *.split]
remexre has quit [*.net *.split]
f-a has joined #forth
remexre has joined #forth
cp- has joined #forth
proteusguy has joined #forth
cp- has quit [Max SendQ exceeded]
<KipIngram>
Yeah. I got my HP 41 in fall of freshman year at UT Austin, and for the rest of college it was my only real computing tool. Honestly I cut my programming teeth programming that. I took a FORTRAN class, but didn't do nearly so much with that as I did the HP. So I was all primed and ready to appreciate Forth. Thinking in terms of a stack was already second nature.
lispmacs[work] has quit [Ping timeout: 265 seconds]
cp- has joined #forth
<KipIngram>
In particular, think in terms of a four element stack, where data just pushed off the top and permanently reproduced on drops was second nature. So there was some adjusting to do.
mark4 has quit [Ping timeout: 260 seconds]
gravicappa has quit [Ping timeout: 252 seconds]
mark4 has joined #forth
tech_exorcist has quit [Ping timeout: 265 seconds]
<tabemann>
back
* tabemann
honestly also just uses Python when he has a calculation he wants to run
<KipIngram>
Too easy.
<KipIngram>
They've really done a good job supporting "quick and dirty."
phadthai has quit [Ping timeout: 265 seconds]
phadthai has joined #forth
andrei-n has quit [Quit: Leaving]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
<veltas>
luajit is my quick and dirty REPL
<veltas>
And my quick and dirty choice of scripting environment too
<veltas>
I love Lua it's a fantastic scripting language
<KipIngram>
My main reason for going with Python is just that's almost always there and has massive package support. I might like lua better for all I know.
f-a has left #forth [#forth]
Zarutian_HTC has joined #forth
<Kumool>
Lua is a fantastic VM, but a terrible scripting language
Croran has joined #forth
<Zarutian_HTC>
the syntax is terrible but man I do love the tables and the metatables
<tabemann>
Lua is lighter-weight than Python, though
<tabemann>
not nearly as lightweight as embedded Forths though
<tabemann>
KipIngram: Lua is far more bare-bones than Python
<tabemann>
Lua is if you have an application written in C or C++ and you want a lightweight scripting language for it
<tabemann>
Python is for if you're scripting something and want the kitchen sink
<KipIngram>
Having that kitchen sink is my usual desire when I use Pythonn.
<KipIngram>
I just want to get something done, fast.
<Kumool>
but it is faster than most forths
<KipIngram>
Not Python.
<KipIngram>
Yuo mean lua?
<Kumool>
aye
<KipIngram>
Gotcha.
<tabemann>
Python is not in itself fast - but it can be fast when you're calling code in C from it
<KipIngram>
Sure.
<KipIngram>
Python is good "glue" for stiching together other things.
<tabemann>
so one can have fast numerics code written in Python even though Python itself is slow as mud
<tabemann>
Python is my go-to language when I want to munge a pile of text and I want it done fast (by fast I mean time spent writing the code)
<Kumool>
I've only tested euler 7, and python is by far faster than awk, but only 2x
<tabemann>
as the code will probably never be run more than a few times anyways
<KipIngram>
I timed an almost empty loop, that just counted a value down from 10 billion, in Forth (mine), Python, and gcc.
<KipIngram>
Python was about 1% of gcc speed - the Forth was about 35% of gcc speed.
<KipIngram>
The Forth word was just
<KipIngram>
: countdown 1- .0>me drop ;
<Kumool>
not much of a benchmark, but I find it more realistic than a noop
<tabemann>
is your Forth ITC, DTC, or STC, and does it have inlinig?
<KipIngram>
ITC.
<Kumool>
strangely enough, lua is slower than perl if you want to mess with text
<KipIngram>
I have some assembly support, but it's barely finished work annd not really honed yet.
<KipIngram>
the 0>me jumps back to the beginnningn of the word if the counter is > 0. Which in this case just means jumping back to the 1-.
<KipIngram>
So that's really two passes through NEXT and a couple of other assembly instructions that do the actual work.
<KipIngram>
Based on that I estimated that my NEXT consumes about 1.5 ns.
<KipIngram>
tabemann: I've always just had a preference for ITC.
<KipIngram>
It's the first Forth architecture I learned about, and I really just built my thinking about it.
<KipIngram>
I think dave0 is onto the best DTC approach - if I ever do one of those I'm pilfering it. :-)
<KipIngram>
He uses the return instruction as his NEXT.
<tabemann>
my embedded forth is SRT/NCI
<KipIngram>
And if he wants to he can put (:) inline just before new definitions with not much space required.
<KipIngram>
That would scream, I think.
<KipIngram>
Did you find CREATE / DOES> to be somewhat cumbersome to implement?
<tabemann>
I should install microPython on one my boards and do a comparison between zeptoforth and it
<KipIngram>
To the extent I've thought about it, I've felt that ITC makes CREATE / DOES> easier.
<tabemann>
my CREATE cannot be used with DOES> - rather I have <BUILDS, which is used with DOES>
<KipIngram>
Ok, that's fair enough. I actually used a different word too - I caled it MAKER.
<KipIngram>
And I was able to implement that all in Forth - I didn't have to use assembly to get there.
<tabemann>
my building words generally call into the zeptoforth kernel, which is written in assembly
<tabemann>
aside from : , :NONAME , and CONSTANT etc, which are part of the kernel itself
<KipIngram>
I wouldn't know what to call the "kernnel" of my Forth.
<KipIngram>
The QUIT loop is right down there at the bottom - I'd say that's the lowest level thing running on the system.
<tabemann>
the kernel of my forth is actually pretty big; it's about 27K
<KipIngram>
My whole Forthis probably somewhere around that.
<KipIngram>
I don't know for sure yet where this onen will wind up.
<KipIngram>
Lemme see where it is now.
<tabemann>
oh my full forth, with all the extras loaded, gets quite big
<KipIngram>
Looks like I'm at 9975 bytes so far.
<KipIngram>
That's the sum of the body section and the header section.
<tabemann>
that's far, far smaller than the "big" zeptoforth builds
<KipIngram>
I'd say this one is just a fairly standard FIG like build, using 32-bit cells in the definitions.
<KipIngram>
I think if it were a 16-bit Forth it would be coming in at this point around 6800 bytes.
<KipIngram>
Maybe a little bigger - some of what I just chopped in half is code, and it wouldn't really reduce much.
<KipIngram>
The CFA/PFA pointers are also 32 bits.
<KipIngram>
A real FIG build wouldn't have the PFA pointers - the definitions and stuff would just start where those are.
<KipIngram>
I didn't want to have to have the headers intermingled with the definitions.
<tabemann>
the "big" zeptoforth is essentially a soft realtime OS
<KipIngram>
It sounds interesting.
<tabemann>
of course the "big" builds for the L4 come out at about ~150K and those for the F4 and F7 come out at 256K due to erase page boundaries
<tabemann>
which is a horrible waste of flash of course
<KipIngram>
This sounds like it's meant as a foundation layer for stuff to run on top of?
<KipIngram>
Or is it supposed to support multiple Forth threads on top of this kernel?
<KipIngram>
I had a task ring designed into my last one, but I never got around to putting more than onen task in it.
<KipIngram>
Each task would have had a 4k page that contained its stacks and a set of important variables. A register pointed to the base of the task page.
<tabemann>
it's supposed to be an environment where one can run multiple preemptive tasks running forth code, with also support for priority inversion-resistant locks, buffered and rendezvous channels, a lightweight event scheduler, task pools, an optional heap allocator, and so on
<KipIngram>
So the idea was that to switch tasks you'd stash your stack pointers, flip that register to the next task's block, and reload the stack pointers and go.
<KipIngram>
Cool.
<tabemann>
the multitasker of course supports multiple task priorities and varied task timeslices, with support built in for sleeping tasks until a time is reached
<KipIngram>
Yeah, I was planning on implementing all that sort of stuff.
<tabemann>
note that this stuff is not implemented in the kernel
<tabemann>
rather most of the traditional "OS"-type stuff aside from the REPL is implemented in Forth
<veltas>
Oh people always moan about Lua's syntax, it's not exactly COBOL
<veltas>
Its syntax is actually quite good, people just don't like some of the choices in the basic syntax
<veltas>
Stuff like 1-based indexing, english words used for scoping, ~= is "not equals"
<veltas>
That's it, if you can get over that the rest is good, and it's so small and easy to learn/apply
<veltas>
Unlike Python where the syntax is actually mostly sensible despite syntactic indentation, but all the core library decisions are horrific and make you wonder why you bothered leaving C
<tabemann>
my main issue with Lua is that I'm not a fan of 1-based indexing, even though I'm willing to put up with it
<veltas>
Lua lets you use 0-based arrays
<veltas>
But the basic list-style constructor will produce 1-based and it's the assumption for most utilities
<tabemann>
yeah
<veltas>
But if you have an isolated situation where you want a 0-based array there's nothing stopping you
<veltas>
I gave a talk about Lua where I gave an example of a circular array and used metatables to make it overall neater than you get with a normal 0-based non-extensible language
<veltas>
Metatables are sort of a DOES> feature
<tabemann>
yeah, I'm familiar with them
<veltas>
Just saying in case anyone else is reading
* tabemann
added scripting to a big application using Lua like a decade ago
<veltas>
I wrote an internal package manager in Lua that ran insanely quickly compared to its PHP predecessor
<veltas>
Just kept it simple and applied associative arrays sensibly, Lua is very fast anyway, the runtime is way smaller than PHP
<tabemann>
uck PHP
<veltas>
The original was written in PHP because it was available on the target machines
<veltas>
Alternatives were like Perl, bash
<tabemann>
I know a lot of cheap web hosting uses PHP
<veltas>
I didn't write the original
<veltas>
PHP is very developed now and apparently not terrible
<veltas>
I can't really comment on it, I have little experience with it
<veltas>
If I had to write a web thing and I had no particular ecosystem requirements I'd use luajit
<tabemann>
I did a little in PHP a long time ago and was not really impressed
<veltas>
PHP is a very unnecessary language, but really all of the web stack is that
<tabemann>
currently at work I work in Java and JavaScript, neither of which I am fond of
<veltas>
luajit or C (or Forth :3)
<veltas>
The biggest problem with Java is Java programmers
<veltas>
And Java codebases
<tabemann>
the Java codebase I work on at work makes me wonder how one actually creates new web applications in Java
<tabemann>
just too much needs to be implemented to get off the ground
<tabemann>
Spring and Maven and Hibernate oh my
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]