Cowgol: actually a thing

Got a programming project in mind? Tell everyone about it!
User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Cowgol: actually a thing

Postby hjalfi » Wed Oct 11, 2017 11:07 pm

(This is a new topic because the previous one was misleadingly titled and had degenerated into me complaining about how terrible the 6502 was. Plus, this is a major milestone. Is that okay?)

I am very pleased, gleeful even, to announce the first proper release of Cowgol, my almost self hosted fully compiled, properly strongly typed, Ada-inspired programming language for the 6502! Which is written in Cowgol itself!

https://github.com/davidgiven/cowgol

The documentation is either markdown files in the github repo, or here: http://cowlark.com/cowgol

...and here is an ADF to prove it, which you can run on a BBC with 6502 Tube:
bbcdist.adf.zip
(56.12 KiB) Downloaded 2 times


That floppy, which is an ADFS-M image (Cowgol is too awesome for a DFS disk; more accurately, it's too awesome for the 200kB maximum disk size), contains the full, massive, eight-stage compiler and will let you compile small programs into proper executables.

Now for the bad news. Apart of being ridiculously buggy, undocumented, and unfinished in many ways, it's also really, really slow. Like, compiling "Hello world!" takes eight minutes on b-em. I don't know how fast b-em's emulated floppy disk is, so if anyone wants to give this a try on real hardware and time it, and maybe even video it, that would be hilarious^H^H^H^H^H^H^H^H^Hhelpful.

The code generated is pretty bad, but... it is running on a machine with, um, slightly more memory than my wristwatch (curse you, Pebble).

I'll do a proper writeup and maybe even some documentation tomorrow.

(I'll update this if more releases ever happen.)
Last edited by hjalfi on Thu Oct 12, 2017 10:42 pm, edited 1 time in total.

User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Cowgol: actually a thing

Postby hjalfi » Wed Oct 11, 2017 11:19 pm

...and I just found the first bug! Looks like there's something wrong with the things table --- there are duplicate entries when the offset is bigger than 0x8000. Sigh.

Incidentally, if you ever want to know what a BBC Micro sounds like when it's swapping, Cowgol is for you.

User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Thu Oct 12, 2017 7:06 am

Congratulations! I'm following this with great interest.

User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Cowgol: actually a thing

Postby hjalfi » Thu Oct 12, 2017 10:42 pm


User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Fri Oct 13, 2017 4:12 am

Have you a way to see how the performance would be using a machine with any kind of solid state storage? That's the modern norm - no head movement, no rotational delay.

User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Cowgol: actually a thing

Postby hjalfi » Fri Oct 13, 2017 1:40 pm

I don't actually have any real hardware, so all this is running on an emulator. I mostly use b-em. I've noticed that b-em's floppy disk noises aren't accurate, and it just classifies seeks into single step / short / medium / long, with timings to match, so I believe it's unfairly slow. Without the floppy disk noises it's a lot faster but that might be unfairly fast.

I should try creating an emulated hard drive image and seeing how that behaves. Anyone have real hardware who wants to give it a try?

I think, however, that the main problem is a combination of Cowgol being slow and the MOS file system APIs being slow. If every byte access needs an RPC across the tube and then multiple bank switches on the I/O processor end before they hit the buffer, it's going to be painful. One thing I want to try is my own disk buffering inside the Cowgol binaries, but I'll need to free up some RAM for that first.

I'm also going to try and get MAME set up, which I believe has more accurate floppy disk emulation, and see what the performance is like there.

User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Fri Oct 13, 2017 5:36 pm

I believe Alan Cox felt the MOS performance was too slow to support a comfortable Fuzix experience. You are, by the sound of it, pushing the file system hard too. As you say, some buffering (or other intelligence) at the application level could make a big difference.

Many - perhaps most - modern users of co-processors have modern hardware which can run a lot faster than the historical 3MHz or 4MHz. That might help some aspects of Cowgol, but not those aspects which are I/O limited.

I could in principle help with benchmarking, as I have a setup with solid state storage and a fast modern copro. All I'd need is the getting my act together.

dp11
Posts: 675
Joined: Sun Aug 12, 2012 8:47 pm

Re: Cowgol: actually a thing

Postby dp11 » Fri Oct 13, 2017 5:39 pm

If you went down the PiTubeDirect route then the 6502 can address much more than 64K RAM by page swapipng.

User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Fri Oct 13, 2017 5:43 pm

A very good point - applies also the Matchbox, for those running an up to date release of the design. Same I/O interface for the banking.

User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Cowgol: actually a thing

Postby hjalfi » Sun Oct 15, 2017 1:13 pm

I got it running in MAME, with hopefully more accurate timing and floppy disk noises:

https://www.youtube.com/watch?v=1wLATW7sVXs

The bad news is that the 'Hello, world!' compilation now takes 1010 seconds, or nearly seventeen minutes.

It sounds like nearly all the time is spent waiting for disk seeks and drive spinups. I'll need to have a go using an ADL file instead of an ADF one; because they're double-sided, you get twice as much data per track, which means less seeking and faster transfers. But I don't expect it to make much difference.

This is all yak shaving, anyway; the only thing which would really help is to simply do less work.

User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Sun Oct 15, 2017 1:50 pm

Presumably it's not helping that you're also compiling the support library from source. Is the setup such that it could be compiled once, and linked in at a late stage?

User avatar
hjalfi
Posts: 70
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Cowgol: actually a thing

Postby hjalfi » Sun Oct 15, 2017 5:57 pm

Not really --- the internal representation doesn't use symbols, so there's no way for two object files to tell each other when they're referring to the same object. Also, the classifier phase needs access to the entire program in order to build the graph to do variable placement (which is the magic bit which makes the whole thing feasible).

(It's tokeniser -> parser -> typechecker -> blockifier -> classifier -> codegen -> placer -> emitter.)

That said, it would be pretty easy to allow incremental tokenisation and probably parsing, which are two of the really slow bits. That would allow the standard libraries to be parsed once and then reused for every user program. You'd still need to typecheck the entire program, though. Once the classifier runs, unused subroutines will be ignored so speed then is based on how much the program actually does.

...pause while I perform measurements...

Yeah, tokenising and parsing consume nearly half the time. Right now, it's:

Tokeniser: 383 seconds
Parser: 160 seconds
Typecheck: 159 seconds
Blockifier: 187 seconds
Classifier: 61 seconds
Codegen: 108 seconds
Placer: 59 seconds
Emitter: 100 seconds

User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Cowgol: actually a thing

Postby BigEd » Sun Oct 15, 2017 6:09 pm

Interesting to know - thanks for the measurements. I'm going to suppose you're in the first part of "make it work first, then make it work fast!" Having something which works is no mean feat - well done!


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest