Cowgol: actually a thing

Got a programming project in mind? Tell everyone about it!
User avatar
hjalfi
Posts: 74
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 6 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: 74
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: 1495
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: 74
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: 1495
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: 74
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: 1495
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: 707
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: 1495
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: 74
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: 1495
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: 74
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: 1495
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!

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

Re: Cowgol: actually a thing

Postby hjalfi » Sun Nov 05, 2017 7:25 pm

Belated, due to other projects and Windows barfing on my Linux partition... thankfully all my actual *data* was elsewhere, but it did take a while to figure out how to build MAME again.

I hacked in support for precompiling the standard library, allowing you to skip about 8 minutes of boilerplate for every compilation. (All it does is tokenisation and parsing.)

Time to precompile the standard library: 590 seconds.
Time to compile 'Hello, world!': 585 seconds.

Combined, it was 1010 seconds... this is on MAME with realistic floppy disk timings.

It looks like a lot of the time is spent seeking from track 0 where the directories are to about track 70 where the data is; this takes a good second every single time. I experimented with using a second disk so that I can read from one and write to the other. It helps no end, but the configuration's a bit fragile. Also, the time spent doing every chunk of work is just enough time for the floppy drive to spin down, so there's more time waste waiting for it to spin up again. Isn't this configurable somewhere? It'd be interesting to bump it up to a few seconds and see what happens.

Realistically, of course, this needs a hard drive.

User avatar
Pernod
Posts: 1001
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: Cowgol: actually a thing

Postby Pernod » Sun Nov 05, 2017 8:13 pm

hjalfi wrote:Also, the time spent doing every chunk of work is just enough time for the floppy drive to spin down, so there's more time waste waiting for it to spin up again. Isn't this configurable somewhere?

Are you referring to the disc timings set by the keyboard dipswitch? If yes then these can be set from the Dip Switches menu.

Also be aware that the 1770 implementation in MAME is much more accurate than the 8271.
You can select either at startup:
mame bbcb -fdc acorn8271
mame bbcb -fdc acorn1770
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest